One Server to rule them all!

So yesterday I was asked for the top-5 reasons that make Crossbar a prime-candidate for the Dynamic Web-server of tomorrow, although I guess that should really that should read "today". The question was partially inspired by the recent sale of Nginx to F5 (for a very large sum of money) which presented the question; "so what is the next generation of technology worth?!".

The bullet point answer in no particular order;

• Communication over Low latency WAMP (10x more efficient than HTTP)
• Real-time two way client-server communication
• Implicit support for modern reactive frameworks like REACT.js and VUE.js
• Routed connections allow data provisioning and consumption anywhere
• Built-in support for new technologies like Block-chain, TOR and Jupyter

Expanding on this "in full" would require many more bullet points (and time) that would probably make this article exceed it's target word-count, but just to clarify some of the above in more detail, from a web developers perspective, this is what Crossbar as a web-server looks like architecturally.

Now this is not an official diagram, nor is it exhaustive in terms of describing the full feature-set, but from my perspective as a full-stack developer it does cover many of the features that are important to me.

Just to expand on a couple of important points;

• Routed connections - this in isolation may not seem to mean much as a feature, but what it really means is that connections between all components are routed (via one or more message routers) which means that any node (anywhere) can talk to any other node connected to the same network. So for example, you could use this feature to allow your web based application to securely access your mobile phone, another machine's web browser, or maybe your home's electricity meter. The latter functionality is supported in depth by Crossbar's support for IoT (the Internet of Things) and it's ability to act as an IoT router.
• Low latency and efficiency - yes, really, 10 times. Why? This is all down to WAMP and is very easy to demonstrate. If you open up the developer tools on your browser and take a look in the network section, then load a web page, you will see that every asset loaded over HTTP includes a whole bunch of HTTP Headers, which, if you do a little math will give you an average header size of between 500 bytes and 1k bytes. This is regardless of payload, so if you want to transmit a single byte, you still have the HTTP packet overhead, call it 600 bytes. Now take a look at a WAMP based site, somewhere in the network section on the developer tools you will see a "ws" line, this is the WAMP websocket connection between your browser and the server. WAMP framing is less than 60 bytes, so sending a single byte over this connection is under 60 bytes of transfer, so this one tenth of the bandwidth usage, one tenth of the data to move around in memory, one tenth of the CPU required to generate the headers .. Ok, so I'm approximating a lot on some points, but in reality the 10x pretty much holds up.
• Reactive web frameworks - my preference here is Vue.js. In practice when my application loads it will make either an anonymous or authenticated connection to the (Crossbar) server using one of the many available authentication systems. (Personally I prefer Google oAuth) and from this point onwards I have the ability to load assets via HTTP/S or Websockets/RPC, and exchange data with peers either via RPC or Pub/Sub. The Killer Vue feature in this context is Vuex, which facilitates the sharing of data between independent Vue components. (i.e. it's a shared data store) So it's a simple task to assign handlers that take incoming data from a WAMP connection, then simply store that data within a Vuex store. If you then map your display(s) to this data, whenever data comes in, the associated on-screen component will immediately update via the Vue reactive framework. So for example if you create an array in Vuex and map it to an on-screen table, when data comes in (say via a 'publish') and the handler updates the Javascript array, the table will automatically update on-screen with no manual intervention. Just to put this into context, imagine a stock trading screen with a couple of dozen sparklines, charts and other displays .. all you need do is design the layout, map each widget back to a Vuex variable (list, object, integer etc), the map a handler to funnel incoming data into the right Vuex variable, and you're done .. just sit back and let the data come, your screen is now "alive" with very little coding effort!

I could go on as there is so much more available, but hopefully this at least gives a flavour of what is possible. A couple of years ago I authored a single page application and implemented this kind of reactivity by hand .. repeating the process now, with this combination of technologies would take a fraction of the time.

So going back to one of the questions that inspired this article, if Nginx is worth half a billion, I'm not sure my calculator has sufficient digits to handle Crossbar's value.