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.
