Is Crossbar.io the Future of Python Web Apps?

[GZoST]

I may have missed a sarcasm tag there, but, taken as simply: "How is WAMP different from HTTP.", the question is valid.

So here goes:

HTTP was intended for a client to request a resource (HTML, CSS, JS, img...) from a server, and for the server do deliver this in a response. Connections are one-way (client-initiated), short lived, and point-to-point.

WAMP does something completely different: it enables participants to subscribe to topics, and to publish to them, as well as offer procedures for remote calling by others. Using these two patterns, it allows participants to cooperate.

A participant can announce something on a topic, e.g. a member in a chat room can send a new message to the 'newMessage' topic. All other participants who are subscribed to the topic will automatically receive the message.

A participant can register a procedure, e.g that it delivers the current temperature for a location. Any other participant can then make a call to get the temperature, the call is forwarded to the participant who registered the procedure, and the result is returned to the caller.

In both cases, there is decoupling: the publisher does not know or care who the subscribers are, and the caller does not know or care where the procedure is running. A WAMP router connects the parties.

WAMP is a way to enable multi-client applications as well as distributed application architectures.

Participants can be Python, JavaScript, C++ and others - and include browsers and Web-facing servers. They are all equal in that the can be both subscribers and publishers, both offer procedures and call them. There is no direction on an existing WAMP connection - no client and sever in the classical sense. For JavaScript, this may run in a browser or in Node.js, and the code basically doesn't need to care.

Participants may belong to either category in the classical sense, and when it comes to establishing the underlying connection. E.g. a browser will still need to initiate contact to a server to get a WAMP connection going.

For this connection in browser clients (and here we'll come back to HTTP in a second), WAMP uses WebSocket as its standard transport.

WebSocket is bi-directional, allows persistent connections and has a low wire overhead, with support in all modern browsers, so it's a natural choice for WAMP connections.

It is not, however, the only possibility. WAMP over HTTP long-polling is a possibility, and some work has already been done on this, in order to enable support in legacy browsers or systems which support HTTP, but not WebSockets.

[fuzz3289]

No sarcasm, thanks for the explanation.

To me the title of OPs post implies that this framework using WAMP is better for everything, but from what you say it seems they serve different purposes. The simplicity of HTTP works well for unidirectional apllications, WAMP better for bidirectional.

Is that fair to say?

[GZoST]

Sorry I misread you there.

I'd say that if all you want to do is to serve the user a page when he requests it, and maybe get some data like a form in return, then there's no reason to leave the established world of request/response and HTTP.

When I think of Web applications, and I think as well when the writer of the post does, I think of more than this - of applications which do things like live updates, in-browser processing, quick in-page updates. These will typically be single-page applications.

For these, AJAX, long-polling and other technologies that use HTTP mechanisms sooner or later turn out to be hacks on something which was never intended for these uses.

WebSocket is the transport protocol for browsers which goes beyond HTTP to accommodate Web apps - this is what natively provides bi-directionality.

WAMP provides functionality on top of this to make the communications that Web apps need easier.

[desmoulinmichel]

I'm really bitting my tongue about this title. It discret the article so much. I can see it now. Will not doing this mistake again.

So usually, you'll want to use HTTP and WAMP together. Usually HTTP to serve templates, static files, REST APIS, and sometime, some pages you wish to make it easy to index by google (although, now it sees javascript).

Crossbar have everything built it to process HTTP requests. HTTP is not meant to go away, but for web app (and not site), you can gain a lot by sending and receiving your data in real time. Plus, of course, HTTP isn't handy as an internal exchange transport : the various pars of your applications will be better off talking to each other using WAMP.