3 ms·

Show HN: Bridge, a cross-language RPC messaging system

105 points by dshankar 14y ago

voxx 14y ago
This is going to change the game, I think. It'll come down to cross platform support and security. Once those two bases are covered, the rest will be a walk in the park for Flotype.
SeoxyS 14y ago
At first sight, this seems awesome. I've been looking for something like this for a while. However, The homepage seems to be a little sparse in terms of specifics. Before implementing this as a core part of a product, I'd like to know: - Pricing model? - Seems free for now, but how about when it's out of beta? How are you going to ensure you stay alive without making me go out of business? - How does this work? "Magic scalability" is mentioned, which sets a red flag for me. We process >1B requests a month (and growing), and we've found that even the best tools have to be used carefully. Black box software such as this is very scary. - How is this deployed? Is it on EC2, which would mean low latency between our infrastructure and the bridge servers? Is there an installable version for people who aren't on EC2? Seems to be a requirement, since message / queues and internal apis require low latency to process things quickly. Especially if we're basing our entire internal service-oriented architecture on top of it. I want to love this, but there's a lot of unanswered questions, at least from perusing this site. I've learnt the hard way to not believe in magic.
- dshankar 14y ago
  Hi! I apologize for the sparseness of the website. I'm not a great designer, and this is just my MVP. Pricing model: see http://news.ycombinator.com/item?id=3870726 http://news.ycombinator.com/item?id=3870726 When it's out of beta, there will be a free tier on Flotype Bridge Public Cloud, and a few paid tiers for people that would like us to manage the Bridge server. This is meant for smaller applications. We can handle 1-2 billion messages/day on a single 8-core server. "Magic scalability" refers to the concept of Bridge Services[1]. If you write code to publish a Bridge Service, you can magically scale by simply firing up more instances of that code. You'll read more about this in the docs. This can be deployed anywhere - EC2, Rackspace, or your private datacenter/cloud, whatever! We just need to make kernel/OS level optimizations for each stack. The Flotype Bridge Cloud runs on EC2, but you can buy and run Bridge anywhere you want. Yes, there is an installable version. The goal of Bridge is to build a messaging system for products with very large messaging needs (billions of messages/hour or more). (This is just a beta). For such applications, subsystem latency is crucial, so the primary deployment model is for you to install it next to your application servers. Please email me at darshan @ flotype.com if you have any more questions :) -Darshan [1] Services documentation example in JavaScript: http://www.flotype.com/docs/gettingstarted/js/services http://www.flotype.com/docs/gettingstarted/js/services
xal 14y ago
this seems to solve the same problem that ØMQ solves. Plus SDKs.
- dshankar 14y ago
  Hi! I just brought up the difference in http://news.ycombinator.com/item?id=3870777 http://news.ycombinator.com/item?id=3870777 Thanks Tobi -Darshan
signa11 14y ago
can you describe how timeouts are handled ? thanks !
- dshankar 14y ago
  It's all asynchronous, so there are no timeouts. -Darshan
  - signa11 14y ago
    hmm, probably I dont't understand it that well then. assume that a client sends an async request to a server, but server being down, busy whatever, doesn't respond, a client should be in a position to set a timeout, and take so e action e.g try another server or something. no ?
rll 14y ago
It wasn't really clear to me what the advantages of this is over a ZMQ+Socket.io based system. The aim is a fully-baked SAAS I suppose, but it seems we already have all the pieces to roll our own without too much effort.
- dshankar 14y ago
  ZMQ is for server-server on the backend. Socket.io would be client-server for the frontend. But the pieces in the middle would have to translate between ZMQ semantics and Socket.io semantics and it's all ugly. There is no way for a ZMQ endpoint to directly address a Socket.io client, and always have to go through this complex intermediary component. As I point out in the video, this is the strategy today. Hook up a bunch of different pieces together. Bridge is meant to be a solution that provides the same semantics for server-server and server-client communication. Thanks -Darshan
  - rll 14y ago
    Well, there is a zmq Javascript flash-binding that gives you ZeroMQ semantics all the way to the client: http://www.zeromq.org/bindings:javascript http://www.zeromq.org/bindings:javascript Semantically it is clean, but the flash part is a bit ugly.
CoffeeDregs 14y ago
I totally misread this and, after a glance, thought that it was a nice cross-language RPC library. Like many fiddly bits, whipping up a quick protocol is simple (and I've built one that I like), but I'd be happier to use one that everyone is helping build/maintain/document... But I was wrong... This is a service... or something. The web page suggests library, but the pricing page suggests service. Color me confused. [An aside: these Pusher, PubSub, whatever businesses exhibit very little in the way of barriers-to-entry. As the price to replicate the service falls (as smart folks think "pay for that? I just make it into a gem/pip/AMI!" and crush the implementation costs), I'm curious how these business will survive. See Engine Yard...]
- dshankar 14y ago
  The Flotype Bridge Cloud service is intended to be a free/cheap way for you to try, learn, and use Bridge. Think of it like Joyent's No.de service, which is a free way to host Node.js apps. The technology is actually targeted at larger-scale applications, and enterprise sales is the focus of our business model. We've had some great traction on the enterprise front, but we're not ready to announce that yet. We're not in the business of nickel and diming fellow developers each month.
dirkdk 14y ago
RPC = old skool, ha! What do you differently from Firebase.com? Or objectfabric.com?
- dshankar 14y ago
  Firebase is a backend for your web applications. It's like Parse for web apps. Bridge is a messaging system for server-server and server-client communication.
yummyfajitas 14y ago
Ok, I'll ask the obvious question: how is this an improvement over Thrift, Protocol Buffers or Avro?
- dshankar 14y ago
  None of them handle server-client and are just an RPC layer. Bridge provides the full layer from RPC down to message routing, access control, etc.
  - newhouseb 14y ago
    Thrift provides server-client implementations, see: http://en.wikipedia.org/wiki/Apache_Thrift http://en.wikipedia.org/wiki/Apache_Thrift
micek 14y ago
from a design standpoint, the points are a bit distracting..and to me (not as important as the titles in most cases). I'd rather see the titles aligned to the left as HN currently displays. I think points can be equally important as comments as well as aligned to the right. otherwise, nice work
wavephorm 14y ago
Meh, nodejs makes this type of service obsolete. I can host my own messaging system now, thanks anyways.
okcool 14y ago
I mean, the video is cool, but I don't think the product is very useful.

105 points by dshankar 14y ago

voxx 14y ago

This is going to change the game, I think. It'll come down to cross platform support and security. Once those two bases are covered, the rest will be a walk in the park for Flotype.

SeoxyS 14y ago

At first sight, this seems awesome. I've been looking for something like this for a while. However, The homepage seems to be a little sparse in terms of specifics. Before implementing this as a core part of a product, I'd like to know: - Pricing model? - Seems free for now, but how about when it's out of beta? How are you going to ensure you stay alive without making me go out of business? - How does this work? "Magic scalability" is mentioned, which sets a red flag for me. We process >1B requests a month (and growing), and we've found that even the best tools have to be used carefully. Black box software such as this is very scary. - How is this deployed? Is it on EC2, which would mean low latency between our infrastructure and the bridge servers? Is there an installable version for people who aren't on EC2? Seems to be a requirement, since message / queues and internal apis require low latency to process things quickly. Especially if we're basing our entire internal service-oriented architecture on top of it. I want to love this, but there's a lot of unanswered questions, at least from perusing this site. I've learnt the hard way to not believe in magic.

dshankar 14y ago
Hi! I apologize for the sparseness of the website. I'm not a great designer, and this is just my MVP. Pricing model: see http://news.ycombinator.com/item?id=3870726 http://news.ycombinator.com/item?id=3870726 When it's out of beta, there will be a free tier on Flotype Bridge Public Cloud, and a few paid tiers for people that would like us to manage the Bridge server. This is meant for smaller applications. We can handle 1-2 billion messages/day on a single 8-core server. "Magic scalability" refers to the concept of Bridge Services[1]. If you write code to publish a Bridge Service, you can magically scale by simply firing up more instances of that code. You'll read more about this in the docs. This can be deployed anywhere - EC2, Rackspace, or your private datacenter/cloud, whatever! We just need to make kernel/OS level optimizations for each stack. The Flotype Bridge Cloud runs on EC2, but you can buy and run Bridge anywhere you want. Yes, there is an installable version. The goal of Bridge is to build a messaging system for products with very large messaging needs (billions of messages/hour or more). (This is just a beta). For such applications, subsystem latency is crucial, so the primary deployment model is for you to install it next to your application servers. Please email me at darshan @ flotype.com if you have any more questions :) -Darshan [1] Services documentation example in JavaScript: http://www.flotype.com/docs/gettingstarted/js/services http://www.flotype.com/docs/gettingstarted/js/services

xal 14y ago

this seems to solve the same problem that ØMQ solves. Plus SDKs.

dshankar 14y ago
Hi! I just brought up the difference in http://news.ycombinator.com/item?id=3870777 http://news.ycombinator.com/item?id=3870777 Thanks Tobi -Darshan

signa11 14y ago

can you describe how timeouts are handled ? thanks !

dshankar 14y ago
It's all asynchronous, so there are no timeouts. -Darshan
- signa11 14y ago
  hmm, probably I dont't understand it that well then. assume that a client sends an async request to a server, but server being down, busy whatever, doesn't respond, a client should be in a position to set a timeout, and take so e action e.g try another server or something. no ?

rll 14y ago

It wasn't really clear to me what the advantages of this is over a ZMQ+Socket.io based system. The aim is a fully-baked SAAS I suppose, but it seems we already have all the pieces to roll our own without too much effort.

dshankar 14y ago
ZMQ is for server-server on the backend. Socket.io would be client-server for the frontend. But the pieces in the middle would have to translate between ZMQ semantics and Socket.io semantics and it's all ugly. There is no way for a ZMQ endpoint to directly address a Socket.io client, and always have to go through this complex intermediary component. As I point out in the video, this is the strategy today. Hook up a bunch of different pieces together. Bridge is meant to be a solution that provides the same semantics for server-server and server-client communication. Thanks -Darshan
- rll 14y ago
  Well, there is a zmq Javascript flash-binding that gives you ZeroMQ semantics all the way to the client: http://www.zeromq.org/bindings:javascript http://www.zeromq.org/bindings:javascript Semantically it is clean, but the flash part is a bit ugly.

CoffeeDregs 14y ago

I totally misread this and, after a glance, thought that it was a nice cross-language RPC library. Like many fiddly bits, whipping up a quick protocol is simple (and I've built one that I like), but I'd be happier to use one that everyone is helping build/maintain/document... But I was wrong... This is a service... or something. The web page suggests library, but the pricing page suggests service. Color me confused. [An aside: these Pusher, PubSub, whatever businesses exhibit very little in the way of barriers-to-entry. As the price to replicate the service falls (as smart folks think "pay for that? I just make it into a gem/pip/AMI!" and crush the implementation costs), I'm curious how these business will survive. See Engine Yard...]

dshankar 14y ago
The Flotype Bridge Cloud service is intended to be a free/cheap way for you to try, learn, and use Bridge. Think of it like Joyent's No.de service, which is a free way to host Node.js apps. The technology is actually targeted at larger-scale applications, and enterprise sales is the focus of our business model. We've had some great traction on the enterprise front, but we're not ready to announce that yet. We're not in the business of nickel and diming fellow developers each month.

dirkdk 14y ago

RPC = old skool, ha! What do you differently from Firebase.com? Or objectfabric.com?

dshankar 14y ago
Firebase is a backend for your web applications. It's like Parse for web apps. Bridge is a messaging system for server-server and server-client communication.

yummyfajitas 14y ago

Ok, I'll ask the obvious question: how is this an improvement over Thrift, Protocol Buffers or Avro?

dshankar 14y ago
None of them handle server-client and are just an RPC layer. Bridge provides the full layer from RPC down to message routing, access control, etc.
- newhouseb 14y ago
  Thrift provides server-client implementations, see: http://en.wikipedia.org/wiki/Apache_Thrift http://en.wikipedia.org/wiki/Apache_Thrift

micek 14y ago

from a design standpoint, the points are a bit distracting..and to me (not as important as the titles in most cases). I'd rather see the titles aligned to the left as HN currently displays. I think points can be equally important as comments as well as aligned to the right. otherwise, nice work

wavephorm 14y ago

Meh, nodejs makes this type of service obsolete. I can host my own messaging system now, thanks anyways.

okcool 14y ago

I mean, the video is cool, but I don't think the product is very useful.