7 ms·

Bridge is a new RPC framework for building modular services

219 points by dshankar 14y ago

lincolnq 14y ago
I've been using their system for a couple months now and it's a really excellent framework for building real-time apps of any sort.
fein 14y ago
I like it, but no PHP option? "Write each component in the language best suited for the job. " Or is this supposed to be a subtle stab?
- vitus 14y ago
  More clients are on the way, judging by their roadmap (see https://www.getbridge.com/about/roadmap https://www.getbridge.com/about/roadmap).
double051 14y ago
You're node broke.
- tedchs 14y ago
  Why do companies keep running their "marketing" sites on application server platforms? Put it on S3 or your Web host of choice, as a good old fashioned static site, and your uptime will go through the roof. Especially for a company that wants to be other people's infrastructure provider...
  - shykes 14y ago
    Plug: dotCloud has a service called static exactly for that :) http://docs.dotcloud.com/services/static/ http://docs.dotcloud.com/services/static/
  - regularfry 14y ago
    A/B testing, at a guess.
- troyk 14y ago
  Looks like the didn't set NODE_ENV to production...
- akshaym 14y ago
  Your* Not sure about this, but I think it's what you mean. I googled "node broke", and didn't come up with meaningful results, so I assume it's "Your". Correct me if I'm wrong!
grantjgordon 14y ago
Has anyone used this on live software with serious traffic? I really like the concept.
devrim 14y ago
awesome. it's not bridge, it's rosetta stone.. this will end religious wars between languages :) will bring them together.. now we can use haskell for X ruby for Y and Z for T. distribute them to different servers. very cool.
ritikm 14y ago
The guys behind this are some of the smartest people I've worked with. I've been using Bridge ever since their beta launch, and they've personally help me get set up, responded to every support request I've had, and delivered on everything they promised for Bridge. It's been super useful for all types of projects -- I've seen it used in tons of small 24 hour hackathon projects, and have used it to scale my own app and port it over to mobile with very little friction. Definitely recommend this piece of technology.
zaptheimpaler 14y ago
This is magic as far as I can tell... How can this be so far ahead of everything else out there?! Anyone have any insights on how this works and what the performance/flexibility tradeoffs are for this magic?
- deleted 14y ago
  [deleted]
- paulhodge 14y ago
  It's not that magic; this kind of development is what message queues have been enabling for years (ActiveMQ, ZeroMQ, RabbitMQ, etc). It's a nice way to architect systems. Bridge looks like a nice evolutionary step forward, in terms of elegance & consistency. Message queues aren't a silver bullet of course, they introduce a lot of potential problems which need to be solved on a case-by-case basis. Such as, what happens if a receiver dies before handling a message? Do senders need to retry sending messages or can they fire-and-forget? Is retrying built in to the queue layer? What happens if a receiver is bogged down with too many messages? Is there a limit on the incoming queue size and what is the limit? Can we start dropping messages if we're overloaded; which messages can we drop? If you make a request that expects a reply, should you timeout and what timeout duration should you use? When a new handler joins the system, should they instantly receive messages that have been waiting for them, or should they dump the existing queue? And so on..
  - zaptheimpaler 14y ago
    Thank you for the explanation, this is blowing my mind because I had no idea message queues existed! Given that, this is a great abstraction for RPC on top of an MQ.
giulianob 14y ago
How does this differ from something like Apache Thrift?
- vitus 14y ago
  Thrift was designed for server-server and primarily for static languages. IDLs are a pain in the ass. Bridge looks like a good alternative. Stuff like client-server, binary data serialization, and no IDLs makes Bridge very appealing. Take a look at Evernote[1]. They needed something like this, and it sounded like they grudgingly went with Thrift. Bridge might be what they needed. http://blog.evernote.com/tech/2011/05/26/evernote-and-thrift/ http://blog.evernote.com/tech/2011/05/26/evernote-and-thrift...
  - chad_walters 14y ago
    Full disclosure: I did some work on Thrift in 2007-2008. I read the blog post you linked and I don't see any real evidence that their choice of Thrift was "grudging". They did say that there are differing requirements that might lead to others to make a different choice -- but AFAICT there is no indication in the article that they regret their choice. WRT IDLs: YMMV of course, but the post you linked provides the following reasons why an IDL might be a good idea: "A more formal IDL and native code generation may help provide better long-term client stability, so the initial Thrift overhead for developers might be justified for some services that are concerned about client stability and longevity."
postfuturist 14y ago
Looks like a nice API (in a few languages) on top of some basic AMQP functionality backed by RabbitMQ. We're building something rather similar (for internal use, not a product). Might have to keep my eye on it, though it's hard to tell what it would cost for server licenses from the webpage. The core server is closed source with rate-limited free binary downloads.
- axx 14y ago
  yep, my first thought was "seems like a nice RPC wrapper around AMQP".
sharadmv 14y ago
i've been using bridge to connect things that you wouldn't think is possible/easy, ranging from connecting android phones to RC blimps to web pages to remote python scripts. it was completely seamless! awesome piece of technology
- halfnelson 14y ago
  Bridge was a lifesaver for the blimp project! Without it we would have had to drop $70 on a bluetooth module and send commands over a serial connection. here's a video of our blimp: http://photos.zyron.me/Other/2012-04-29/22712358_zSZWhh#!i=1820650079&k=zHFPXnK&lb=1&s=A http://photos.zyron.me/Other/2012-04-29/22712358_zSZWhh#!i=1...
talentdeficit 14y ago
the server seems to be written in erlang (using cowboy and rabbitmq?) but there's no erlang client library available. what gives?
- dshankar 14y ago
  We're working on more clients! We figured we'd release with just a few to begin with.
- astrodust 14y ago
  The cobbler's children don't get any shoes, huh?
tupshin 14y ago
Looks interesting but very similar in concept to Mongrel2 built on top of zeromq.
- sthatipamala 14y ago
  Good observation. They are actually pretty similar but with different implementations. We're implemented with an Erlang cowboy server that interfaces with RabbitMQ for routing. From what I've seen mongrel2 is designed as a HTTP/REST -> 0MQ gateway. We also have HTTP/REST endpoints in the works but we're designed with persistent WebSockets/TCP in mind.
jtchang 14y ago
The most useful page for me was how to do a local install: https://www.getbridge.com/docs/install https://www.getbridge.com/docs/install It looks like it is built on top of rabbitmq. I will be keeping an eye on these types of frameworks because I want to see how far the framework can go in the stack. Specifically I am waiting for frameworks that help me manage my web UI in an easy manner.
AjayTripathy 14y ago
I've already built a cool hack with bridge! The multi-language support allowed me to use node.js for my IO and python for my logic. They interfaced pretty seamlessly. This is a good tool for hackers.
metabrew 14y ago
Looks nice, but there's no way I'd run a closed source binary only server as a critical piece of infrastructure like this. Planning on selling licenses I suppose? I would have loved to have a poke around in the erlang server code. Cowboy/rabbit/messaging - sounds fun.
- dshankar 14y ago
  Shoot me an email[1]. We're not open source, but I'm happy to show you the code! As I said in comments above, if the source is really important to you, I can walk you through it and give you access so that you feel comfortable about what you're adopting. We're just not ready to open source the server yet. You don't even need to pay for a server license until you're doing thousands of messages per second! At those scales, you should be able to afford cheap licenses. We're not focused on making small amounts of money from ramen startups or hungry students. We do have a good business in enterprise software to fund the free Bridge Cloud servers. [1]: darshan@getbridge.com
  - CJefferson 14y ago
    It might be worth considering introducing a Qt-style "if we ever go under, or stop, the source is released Under BSD". No offence to you, but I have sen too many companies go bankcrupt, or get bought out and shut down, to trust such important infrastructure to you!
    - dshankar 14y ago
      This has been proposed with some of our enterprise contacts, as they share your same concern. I'll take a closer look!
newhouseb 14y ago
Looks cool, but - is Bridge an open source project? Is it a company? All of the above? Do I have to pay for it? What are the prices? As someone who makes architectural decisions on a regular basis, I need to know that if a company that we're a dependency on dies, we can rip it out and replace it with a) an open source version of what we were paying for or b) our own alternative implementation (which sounds like something on top of RabbitMQ in this case). It's frustrating to see companies like this positioning themselves in a way that makes them difficult to evaluate.
- deleted 14y ago
  [deleted]
- deleted 14y ago
  [deleted]
- dshankar 14y ago
  We're a well funded company. We've raised money from A16Z, Salesforce.com, and a bunch of others.[1] We have open sourced the clients but Bridge Server is not open source.[2] How do we make money? We're building this type of software for much larger organizations (think enterprise & government). We're not in the business of charging hackers and students $5. We're likely going to charge some money for Bridge Cloud as a lot of the startups currently using Bridge prefer to use & pay for Bridge Cloud. It's the peace of mind of not having to deal with ops on a messaging server. Bridge server itself will also cost some money. But the point is that we're only going to charge the big guys who can easily afford such systems. Their alternative today is to spend tens of millions on an engineering team to build systems in house. There will always be a generous free tier for Bridge. You can download Bridge right now and pump 40,000 messages per minute through it for FREE. Do you need more? Just call me, I'm happy to bump you up.[3] We have a setup for companies paying us and need to see the source code. If it's really important to you, we're happy to show you the code. What can I do to help you evaluate Bridge? Can you shoot me an email? I'm at darshan@getbridge.com. [1]http://techcrunch.com/2012/01/05/andreessen-horowitz-salesforce-put-1-4m-in-real-time-messaging-infrastructure-startup-flotype/ http://techcrunch.com/2012/01/05/andreessen-horowitz-salesfo... [2]http://github.com/getbridge http://github.com/getbridge [3]https://www.getbridge.com/start https://www.getbridge.com/start
kbd 14y ago
ZeroRPC was just linked a few days ago[1] and this sounds similar. Both even use MessagePack for serialization. How are they different/similar? [1] http://news.ycombinator.com/item?id=4147337 http://news.ycombinator.com/item?id=4147337
- sthatipamala 14y ago
  ZeroRPC is pretty cool but it's a different concept. It uses 0MQ sockets as the transport whereas we use RabbitMQ. This allows us to do zero-configuration service discovery and complex routing. Bridge allows you to securely expose APIs to "untrusted" clients such as browsers and mobile clients. ZeroRPC does not do this because 0MQ doesn't allow such access control.
  - kbd 14y ago
    Neat, thanks for your response. Question for you: on your roadmap[1] you write: > Efficient binary data transfer > This would allow for some interesting applications such as video streaming, file transfer, image processing and more. Binary data support was one of the key reasons Github chose to roll its own serialization format (BERT) instead of using existing options. Why is BERT > MessagePack for this? [1] https://www.getbridge.com/about/roadmap https://www.getbridge.com/about/roadmap
    - sthatipamala 14y ago
      To clarify, Bridge's binary serialization will be MessagePack. Github's BERT is also good for binary serialization but we decided to go with MessagePack because of its wide language support. I don't think BERT-RPC is necessarily _better_ for binary. But we referenced it in the roadmap as a good idea that we derived inspiration from.
  - shykes 14y ago
    sthatipamala is correct. A few more points on the differences between ZeroRPC and Bridge: * ZeroRPC has been open-sourced by dotCloud with no plans for monetization. It's just a fundamental piece of infrastructure which we think is worth sharing. Licensing fundamental infrastructure software is not our business (also: it's very hard). * I see very interesting scenarios where ZeroRPC can be integrated with Bridge. There is already work on integrating it with systems very similar to Bridge, for example Stack.io (http://github.com/dotcloud/stack.io http://github.com/dotcloud/stack.io).
wordstospend 14y ago
We've been talking about this around our shop. No small amount of thought goes into considering whether to use a service or tool or not. And that can greatly depend on if it has a web api or needs glue code to fit into our world. Both Facebook and Google use similar message layer systems to keep the chimera cluster f*cks they have working. The problem will be keeping bridge lean enough to do what it needs to, and small enough that you know what it does.
- dshankar 14y ago
  We're really focused on lightweight simplicity right now. Keeping Bridge lean is a priority. In terms of a web api vs. glue code, Bridge requires very little if any glue code. Check out our roadmap. We do have a REST endpoint planned. https://www.getbridge.com/about/roadmap https://www.getbridge.com/about/roadmap
cmelbye 14y ago
It's a shame that it's closed source. I'm trying to install it through the installer, and I'm in "missing shared object file" hell due to things not being named as the binary expects them to be.
- dshankar 14y ago
  Oh dear! Can you send me an email? darshan@getbridge.com
10dpd 14y ago
<body style="padding-left:10px">
zoowar 14y ago
The default is to send your private key in plaintext to the redirector.
- sthatipamala 14y ago
  SSL was added recently so it's not the default for now. Thanks for calling us out on this, we'll switch to HTTPS/SSL as the default in coming updates. To enable encryption right now, please see https://www.getbridge.com/docs/gettingstarted/js/advanced https://www.getbridge.com/docs/gettingstarted/js/advanced
  - mcguire 14y ago
    Wait. "The default is to send your private key in plaintext to the redirector." What?
    - folz 14y ago
      Your private API key, not your private SSH key.
      - koko775 14y ago
        That clarifies that it's not a good idea, actually. A secure exchange would involve the server issuing a challenge, and the client producing a response, and not sending the key at all.
iuguy 14y ago
I like this, from the examples it looks really useful and I wish these guys well. Kudos to them for building something awesome!
- iuguy 14y ago
  Excuse this, it's a self-reply test after some miscellaneous problems.
yankoff 14y ago
I built something similar but simpler not long ago https://github.com/yankov/nourl https://github.com/yankov/nourl But it only supports ruby on a server side and JS on a client. You guys can simplify your framework in many ways by following convention over configuration principle.
windexh8er 14y ago
Looks fantastic - not being a day-to-day programmer this is exactly what I've been looking for. Building my command and control platform will be significantly easier. Anyone else notice that the pip install is broke though? Complains that 'README.md' is missing from the tarball.
mcguire 14y ago
Ok, the people being quoted on the page all look to be under 25, and so are the people commenting here judging by the comments, so I suspect that no one involved or interested in Bridge has ever used RPC systems before and therefore have no idea how bad they actually are. Or possibly, judging by the "No configuration files or IDLs." comment, they may have heard of SOAP while it was being called an RPC system and be suffering from second system delusions. If you are interested in some of the existing discussion, check out (They're PDFs. Sorry.): * [1988] A Critique of the Remote Procedure Call Paradigm http://www.cs.vu.nl/~ast/publications/euteco-1988.pdf http://www.cs.vu.nl/~ast/publications/euteco-1988.pdf * [1994] A note on distributed computing. http://research.sun.com/techrep/1994/abstract-29.html http://research.sun.com/techrep/1994/abstract-29.html * [2005] RPC under fire. Steve Vinoski. http://www.iona.com/hyplan/vinoski/pdfs/IEEE-RPC_Under_Fire.pdf http://www.iona.com/hyplan/vinoski/pdfs/IEEE-RPC_Under_Fire....
- dshankar 14y ago
  So Google (Protocol Buffers - RPC), Facebook (Thrift - RPC), Twitter (Finagle/Thrift - RPC), GitHub (BERT-RPC), DotCloud (ZeroRPC), Quora (Thrift - RPC) and all major tech companies are wrong? The list of companies using RPC messaging systems is very long. RPC is widely used. It is mature and well understood. "RPC is bad because network calls look like local calls" is a terrible overused argument.
  - m0th87 14y ago
    To some degree, it's a fair critique. RPC is a loaded term, because there were far too many implementations that tried to hide the network, which is a recipe for disaster. We were hesitant of going forward with the name ZeroRPC ourselves because of the historical baggage. That said, most of the faults people have placed on RPC have been products of individual implementations and not the concept itself, and there really is much more momentum behind RPC engines than anything else. For my Master's thesis, I implemented a generative communication [1] engine. While I still feel like it's a "beautiful" model, it turns out no one cares. Developers understand RPC calls. Not that many get tuples / tuplespaces / pattern matching and why that can be nice. 1: http://theory.sci.univr.it/papers/Isa-orig/Varie/Linda2.pdf http://theory.sci.univr.it/papers/Isa-orig/Varie/Linda2.pdf
dudus 14y ago
You have a link to the [bridge] tag on Stack Overflow, even though that tag is supposedly dead: http://stackoverflow.com/tags/bridge/info http://stackoverflow.com/tags/bridge/info
dudus 14y ago
I'm really intersted in seeing the browser javascript part. The javascript gitHub repo seems to be for node only. How do you call RPC directly from Browser Javascript? I'm guessing it does something similar to socket.io, but I haven't tested yet.
folz 14y ago
Hi, I'm the first person quoted on the testimonials page. I've gotten a few emails related Bridge and my job, and I'd like to clarify: The email that quote came from was personal, and not at all related to my employment at Facebook (specifically, it is not an endorsement by Facebook). I use Bridge for personal projects, and that's what my email was referencing. I've asked that my quote be made clearer, and I'm sorry if you were confused or misled by the ambiguity.
bobwaycott 14y ago
Viewing the site from an iPad could use some attention. Both landscape and portrait have some unexpected cutoff and alignment issues that are somewhat distracting.
densh 14y ago
Aren't imports ugly, or is it just me? // js var Bridge = require('bridge-js') // python from BridgePython.bridge import Bridge // ruby require 'bridge-ruby' --- First of all you don't really need language name in the name of each of the bindings. It's kind of obvious that i'm using ruby or python at the moment, isn't it? Python version looks especially ugly it should have been much simpler: import bridge
- dshankar 14y ago
  That would be ideal, but it was not possible to get the `bridge` packages. The word `bridge` is too generic. Sorry about that :(
  - shykes 14y ago
    Maybe something specific yet cross-language, like "bridge-rpc"?
johnx123-up 14y ago
So, Flotype http://www.flotype.com/ http://www.flotype.com/ (from NowJS) is now Bridge? Why?
thedangler 14y ago
I see that even on the client side in JS you need to provide your api-key. How is this secure in that someone else doesn't just use your api key? If it is explained on the site forgive me for not finding it.

219 points by dshankar 14y ago

I've been using their system for a couple months now and it's a really excellent framework for building real-time apps of any sort.

fein 14y ago

I like it, but no PHP option? "Write each component in the language best suited for the job. " Or is this supposed to be a subtle stab?

vitus 14y ago
More clients are on the way, judging by their roadmap (see https://www.getbridge.com/about/roadmap https://www.getbridge.com/about/roadmap).

double051 14y ago

You're node broke.

tedchs 14y ago
Why do companies keep running their "marketing" sites on application server platforms? Put it on S3 or your Web host of choice, as a good old fashioned static site, and your uptime will go through the roof. Especially for a company that wants to be other people's infrastructure provider...
- shykes 14y ago
  Plug: dotCloud has a service called static exactly for that :) http://docs.dotcloud.com/services/static/ http://docs.dotcloud.com/services/static/
- regularfry 14y ago
  A/B testing, at a guess.
troyk 14y ago
Looks like the didn't set NODE_ENV to production...
akshaym 14y ago
Your* Not sure about this, but I think it's what you mean. I googled "node broke", and didn't come up with meaningful results, so I assume it's "Your". Correct me if I'm wrong!

grantjgordon 14y ago

Has anyone used this on live software with serious traffic? I really like the concept.

devrim 14y ago

awesome. it's not bridge, it's rosetta stone.. this will end religious wars between languages :) will bring them together.. now we can use haskell for X ruby for Y and Z for T. distribute them to different servers. very cool.

ritikm 14y ago

The guys behind this are some of the smartest people I've worked with. I've been using Bridge ever since their beta launch, and they've personally help me get set up, responded to every support request I've had, and delivered on everything they promised for Bridge. It's been super useful for all types of projects -- I've seen it used in tons of small 24 hour hackathon projects, and have used it to scale my own app and port it over to mobile with very little friction. Definitely recommend this piece of technology.

zaptheimpaler 14y ago

This is magic as far as I can tell... How can this be so far ahead of everything else out there?! Anyone have any insights on how this works and what the performance/flexibility tradeoffs are for this magic?

deleted 14y ago
[deleted]
paulhodge 14y ago
It's not that magic; this kind of development is what message queues have been enabling for years (ActiveMQ, ZeroMQ, RabbitMQ, etc). It's a nice way to architect systems. Bridge looks like a nice evolutionary step forward, in terms of elegance & consistency. Message queues aren't a silver bullet of course, they introduce a lot of potential problems which need to be solved on a case-by-case basis. Such as, what happens if a receiver dies before handling a message? Do senders need to retry sending messages or can they fire-and-forget? Is retrying built in to the queue layer? What happens if a receiver is bogged down with too many messages? Is there a limit on the incoming queue size and what is the limit? Can we start dropping messages if we're overloaded; which messages can we drop? If you make a request that expects a reply, should you timeout and what timeout duration should you use? When a new handler joins the system, should they instantly receive messages that have been waiting for them, or should they dump the existing queue? And so on..
- zaptheimpaler 14y ago
  Thank you for the explanation, this is blowing my mind because I had no idea message queues existed! Given that, this is a great abstraction for RPC on top of an MQ.

giulianob 14y ago

How does this differ from something like Apache Thrift?

vitus 14y ago
Thrift was designed for server-server and primarily for static languages. IDLs are a pain in the ass. Bridge looks like a good alternative. Stuff like client-server, binary data serialization, and no IDLs makes Bridge very appealing. Take a look at Evernote[1]. They needed something like this, and it sounded like they grudgingly went with Thrift. Bridge might be what they needed. http://blog.evernote.com/tech/2011/05/26/evernote-and-thrift/ http://blog.evernote.com/tech/2011/05/26/evernote-and-thrift...
- chad_walters 14y ago
  Full disclosure: I did some work on Thrift in 2007-2008. I read the blog post you linked and I don't see any real evidence that their choice of Thrift was "grudging". They did say that there are differing requirements that might lead to others to make a different choice -- but AFAICT there is no indication in the article that they regret their choice. WRT IDLs: YMMV of course, but the post you linked provides the following reasons why an IDL might be a good idea: "A more formal IDL and native code generation may help provide better long-term client stability, so the initial Thrift overhead for developers might be justified for some services that are concerned about client stability and longevity."

postfuturist 14y ago

Looks like a nice API (in a few languages) on top of some basic AMQP functionality backed by RabbitMQ. We're building something rather similar (for internal use, not a product). Might have to keep my eye on it, though it's hard to tell what it would cost for server licenses from the webpage. The core server is closed source with rate-limited free binary downloads.

axx 14y ago
yep, my first thought was "seems like a nice RPC wrapper around AMQP".

sharadmv 14y ago

i've been using bridge to connect things that you wouldn't think is possible/easy, ranging from connecting android phones to RC blimps to web pages to remote python scripts. it was completely seamless! awesome piece of technology

halfnelson 14y ago
Bridge was a lifesaver for the blimp project! Without it we would have had to drop $70 on a bluetooth module and send commands over a serial connection. here's a video of our blimp: http://photos.zyron.me/Other/2012-04-29/22712358_zSZWhh#!i=1820650079&k=zHFPXnK&lb=1&s=A http://photos.zyron.me/Other/2012-04-29/22712358_zSZWhh#!i=1...

talentdeficit 14y ago

the server seems to be written in erlang (using cowboy and rabbitmq?) but there's no erlang client library available. what gives?

dshankar 14y ago
We're working on more clients! We figured we'd release with just a few to begin with.
astrodust 14y ago
The cobbler's children don't get any shoes, huh?

tupshin 14y ago

Looks interesting but very similar in concept to Mongrel2 built on top of zeromq.

sthatipamala 14y ago
Good observation. They are actually pretty similar but with different implementations. We're implemented with an Erlang cowboy server that interfaces with RabbitMQ for routing. From what I've seen mongrel2 is designed as a HTTP/REST -> 0MQ gateway. We also have HTTP/REST endpoints in the works but we're designed with persistent WebSockets/TCP in mind.

jtchang 14y ago

The most useful page for me was how to do a local install: https://www.getbridge.com/docs/install https://www.getbridge.com/docs/install It looks like it is built on top of rabbitmq. I will be keeping an eye on these types of frameworks because I want to see how far the framework can go in the stack. Specifically I am waiting for frameworks that help me manage my web UI in an easy manner.

AjayTripathy 14y ago

I've already built a cool hack with bridge! The multi-language support allowed me to use node.js for my IO and python for my logic. They interfaced pretty seamlessly. This is a good tool for hackers.

metabrew 14y ago

Looks nice, but there's no way I'd run a closed source binary only server as a critical piece of infrastructure like this. Planning on selling licenses I suppose? I would have loved to have a poke around in the erlang server code. Cowboy/rabbit/messaging - sounds fun.

dshankar 14y ago
Shoot me an email[1]. We're not open source, but I'm happy to show you the code! As I said in comments above, if the source is really important to you, I can walk you through it and give you access so that you feel comfortable about what you're adopting. We're just not ready to open source the server yet. You don't even need to pay for a server license until you're doing thousands of messages per second! At those scales, you should be able to afford cheap licenses. We're not focused on making small amounts of money from ramen startups or hungry students. We do have a good business in enterprise software to fund the free Bridge Cloud servers. [1]: darshan@getbridge.com
- CJefferson 14y ago
  It might be worth considering introducing a Qt-style "if we ever go under, or stop, the source is released Under BSD". No offence to you, but I have sen too many companies go bankcrupt, or get bought out and shut down, to trust such important infrastructure to you!
  - dshankar 14y ago
    This has been proposed with some of our enterprise contacts, as they share your same concern. I'll take a closer look!

newhouseb 14y ago

Looks cool, but - is Bridge an open source project? Is it a company? All of the above? Do I have to pay for it? What are the prices? As someone who makes architectural decisions on a regular basis, I need to know that if a company that we're a dependency on dies, we can rip it out and replace it with a) an open source version of what we were paying for or b) our own alternative implementation (which sounds like something on top of RabbitMQ in this case). It's frustrating to see companies like this positioning themselves in a way that makes them difficult to evaluate.

deleted 14y ago
[deleted]
deleted 14y ago
[deleted]
dshankar 14y ago
We're a well funded company. We've raised money from A16Z, Salesforce.com, and a bunch of others.[1] We have open sourced the clients but Bridge Server is not open source.[2] How do we make money? We're building this type of software for much larger organizations (think enterprise & government). We're not in the business of charging hackers and students $5. We're likely going to charge some money for Bridge Cloud as a lot of the startups currently using Bridge prefer to use & pay for Bridge Cloud. It's the peace of mind of not having to deal with ops on a messaging server. Bridge server itself will also cost some money. But the point is that we're only going to charge the big guys who can easily afford such systems. Their alternative today is to spend tens of millions on an engineering team to build systems in house. There will always be a generous free tier for Bridge. You can download Bridge right now and pump 40,000 messages per minute through it for FREE. Do you need more? Just call me, I'm happy to bump you up.[3] We have a setup for companies paying us and need to see the source code. If it's really important to you, we're happy to show you the code. What can I do to help you evaluate Bridge? Can you shoot me an email? I'm at darshan@getbridge.com. [1]http://techcrunch.com/2012/01/05/andreessen-horowitz-salesforce-put-1-4m-in-real-time-messaging-infrastructure-startup-flotype/ http://techcrunch.com/2012/01/05/andreessen-horowitz-salesfo... [2]http://github.com/getbridge http://github.com/getbridge [3]https://www.getbridge.com/start https://www.getbridge.com/start

kbd 14y ago

ZeroRPC was just linked a few days ago[1] and this sounds similar. Both even use MessagePack for serialization. How are they different/similar? [1] http://news.ycombinator.com/item?id=4147337 http://news.ycombinator.com/item?id=4147337

sthatipamala 14y ago
ZeroRPC is pretty cool but it's a different concept. It uses 0MQ sockets as the transport whereas we use RabbitMQ. This allows us to do zero-configuration service discovery and complex routing. Bridge allows you to securely expose APIs to "untrusted" clients such as browsers and mobile clients. ZeroRPC does not do this because 0MQ doesn't allow such access control.
- kbd 14y ago
  Neat, thanks for your response. Question for you: on your roadmap[1] you write: > Efficient binary data transfer > This would allow for some interesting applications such as video streaming, file transfer, image processing and more. Binary data support was one of the key reasons Github chose to roll its own serialization format (BERT) instead of using existing options. Why is BERT > MessagePack for this? [1] https://www.getbridge.com/about/roadmap https://www.getbridge.com/about/roadmap
  - sthatipamala 14y ago
    To clarify, Bridge's binary serialization will be MessagePack. Github's BERT is also good for binary serialization but we decided to go with MessagePack because of its wide language support. I don't think BERT-RPC is necessarily _better_ for binary. But we referenced it in the roadmap as a good idea that we derived inspiration from.
- shykes 14y ago
  sthatipamala is correct. A few more points on the differences between ZeroRPC and Bridge: * ZeroRPC has been open-sourced by dotCloud with no plans for monetization. It's just a fundamental piece of infrastructure which we think is worth sharing. Licensing fundamental infrastructure software is not our business (also: it's very hard). * I see very interesting scenarios where ZeroRPC can be integrated with Bridge. There is already work on integrating it with systems very similar to Bridge, for example Stack.io (http://github.com/dotcloud/stack.io http://github.com/dotcloud/stack.io).

wordstospend 14y ago

We've been talking about this around our shop. No small amount of thought goes into considering whether to use a service or tool or not. And that can greatly depend on if it has a web api or needs glue code to fit into our world. Both Facebook and Google use similar message layer systems to keep the chimera cluster f*cks they have working. The problem will be keeping bridge lean enough to do what it needs to, and small enough that you know what it does.

dshankar 14y ago
We're really focused on lightweight simplicity right now. Keeping Bridge lean is a priority. In terms of a web api vs. glue code, Bridge requires very little if any glue code. Check out our roadmap. We do have a REST endpoint planned. https://www.getbridge.com/about/roadmap https://www.getbridge.com/about/roadmap

cmelbye 14y ago

It's a shame that it's closed source. I'm trying to install it through the installer, and I'm in "missing shared object file" hell due to things not being named as the binary expects them to be.

dshankar 14y ago
Oh dear! Can you send me an email? darshan@getbridge.com

10dpd 14y ago

zoowar 14y ago

The default is to send your private key in plaintext to the redirector.

sthatipamala 14y ago
SSL was added recently so it's not the default for now. Thanks for calling us out on this, we'll switch to HTTPS/SSL as the default in coming updates. To enable encryption right now, please see https://www.getbridge.com/docs/gettingstarted/js/advanced https://www.getbridge.com/docs/gettingstarted/js/advanced
- mcguire 14y ago
  Wait. "The default is to send your private key in plaintext to the redirector." What?
  - folz 14y ago
    Your private API key, not your private SSH key.
    - koko775 14y ago
      That clarifies that it's not a good idea, actually. A secure exchange would involve the server issuing a challenge, and the client producing a response, and not sending the key at all.

iuguy 14y ago

I like this, from the examples it looks really useful and I wish these guys well. Kudos to them for building something awesome!

iuguy 14y ago
Excuse this, it's a self-reply test after some miscellaneous problems.

yankoff 14y ago

I built something similar but simpler not long ago https://github.com/yankov/nourl https://github.com/yankov/nourl But it only supports ruby on a server side and JS on a client. You guys can simplify your framework in many ways by following convention over configuration principle.

windexh8er 14y ago

Looks fantastic - not being a day-to-day programmer this is exactly what I've been looking for. Building my command and control platform will be significantly easier. Anyone else notice that the pip install is broke though? Complains that 'README.md' is missing from the tarball.

mcguire 14y ago

Ok, the people being quoted on the page all look to be under 25, and so are the people commenting here judging by the comments, so I suspect that no one involved or interested in Bridge has ever used RPC systems before and therefore have no idea how bad they actually are. Or possibly, judging by the "No configuration files or IDLs." comment, they may have heard of SOAP while it was being called an RPC system and be suffering from second system delusions. If you are interested in some of the existing discussion, check out (They're PDFs. Sorry.): * [1988] A Critique of the Remote Procedure Call Paradigm http://www.cs.vu.nl/~ast/publications/euteco-1988.pdf http://www.cs.vu.nl/~ast/publications/euteco-1988.pdf * [1994] A note on distributed computing. http://research.sun.com/techrep/1994/abstract-29.html http://research.sun.com/techrep/1994/abstract-29.html * [2005] RPC under fire. Steve Vinoski. http://www.iona.com/hyplan/vinoski/pdfs/IEEE-RPC_Under_Fire.pdf http://www.iona.com/hyplan/vinoski/pdfs/IEEE-RPC_Under_Fire....

dshankar 14y ago
So Google (Protocol Buffers - RPC), Facebook (Thrift - RPC), Twitter (Finagle/Thrift - RPC), GitHub (BERT-RPC), DotCloud (ZeroRPC), Quora (Thrift - RPC) and all major tech companies are wrong? The list of companies using RPC messaging systems is very long. RPC is widely used. It is mature and well understood. "RPC is bad because network calls look like local calls" is a terrible overused argument.
- m0th87 14y ago
  To some degree, it's a fair critique. RPC is a loaded term, because there were far too many implementations that tried to hide the network, which is a recipe for disaster. We were hesitant of going forward with the name ZeroRPC ourselves because of the historical baggage. That said, most of the faults people have placed on RPC have been products of individual implementations and not the concept itself, and there really is much more momentum behind RPC engines than anything else. For my Master's thesis, I implemented a generative communication [1] engine. While I still feel like it's a "beautiful" model, it turns out no one cares. Developers understand RPC calls. Not that many get tuples / tuplespaces / pattern matching and why that can be nice. 1: http://theory.sci.univr.it/papers/Isa-orig/Varie/Linda2.pdf http://theory.sci.univr.it/papers/Isa-orig/Varie/Linda2.pdf

dudus 14y ago

You have a link to the [bridge] tag on Stack Overflow, even though that tag is supposedly dead: http://stackoverflow.com/tags/bridge/info http://stackoverflow.com/tags/bridge/info

dudus 14y ago

I'm really intersted in seeing the browser javascript part. The javascript gitHub repo seems to be for node only. How do you call RPC directly from Browser Javascript? I'm guessing it does something similar to socket.io, but I haven't tested yet.

folz 14y ago

Hi, I'm the first person quoted on the testimonials page. I've gotten a few emails related Bridge and my job, and I'd like to clarify: The email that quote came from was personal, and not at all related to my employment at Facebook (specifically, it is not an endorsement by Facebook). I use Bridge for personal projects, and that's what my email was referencing. I've asked that my quote be made clearer, and I'm sorry if you were confused or misled by the ambiguity.

bobwaycott 14y ago

Viewing the site from an iPad could use some attention. Both landscape and portrait have some unexpected cutoff and alignment issues that are somewhat distracting.

densh 14y ago

Aren't imports ugly, or is it just me? // js var Bridge = require('bridge-js') // python from BridgePython.bridge import Bridge // ruby require 'bridge-ruby' --- First of all you don't really need language name in the name of each of the bindings. It's kind of obvious that i'm using ruby or python at the moment, isn't it? Python version looks especially ugly it should have been much simpler: import bridge

dshankar 14y ago
That would be ideal, but it was not possible to get the `bridge` packages. The word `bridge` is too generic. Sorry about that :(
- shykes 14y ago
  Maybe something specific yet cross-language, like "bridge-rpc"?

johnx123-up 14y ago

So, Flotype http://www.flotype.com/ http://www.flotype.com/ (from NowJS) is now Bridge? Why?

thedangler 14y ago

I see that even on the client side in JS you need to provide your api-key. How is this secure in that someone else doesn't just use your api key? If it is explained on the site forgive me for not finding it.