

Show HN: Bridge, a cross-language RPC messaging system - dshankar
http://www.flotype.com/

======
CoffeeDregs
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
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.

------
SeoxyS
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
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>

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

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

~~~
dshankar
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
Thrift provides server-client implementations, see:
<http://en.wikipedia.org/wiki/Apache_Thrift>

------
micek
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

------
dirkdk
RPC = old skool, ha!

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

~~~
dshankar
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.

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

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

Thanks Tobi -Darshan

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

------
signa11
can you describe how timeouts are handled ? thanks !

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

-Darshan

~~~
signa11
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 ?

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

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

