Show HN: Bridge, a cross-language RPC messaging system | Hacker News Reader

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

flotype.com

105 pointsdshankar21 comments

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...]

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.

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.

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

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

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.

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

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

Semantically it is clean, but the flash part is a bit ugly.

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

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.

Thrift provides server-client implementations, see: http://en.wikipedia.org/wiki/Apache_Thrift

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

RPC = old skool, ha!

What do you differently from Firebase.com? Or objectfabric.com?

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.

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

Hi! I just brought up the difference in http://news.ycombinator.com/item?id=3870777

Thanks Tobi -Darshan

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

can you describe how timeouts are handled ? thanks !

It's all asynchronous, so there are no timeouts.

-Darshan

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 ?

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.

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

Reply on news.ycombinator.com