In the past few years, websockets have become more or less a standard component in all modern web applications, but why is that and how did we get here? More importantly, how can websockets help you monitor your cloud infrastructure more effectively?
Due to the technical nature of this topic, it is possible to dive very deep into the details, but I’ll try to keep things at a relatively high-level in this post and focus on the benefits to our cloud infrastructure users.
The old way of doing things
In the early days of the web, everything was static. If you needed to interact with a server (beyond rendering a static page), you would have to execute some kind of CGI-script. A typical example of this was something like a mailing list sign-up, where you would enter your email address, and when you pressed ‘submit,’ you would be taken to a separate page that processed the data (which in turn was a script that took the input and processed it on the server).
By the ‘90s, server-side scripting had evolved significantly. The technology had evolved from executing simple tasks, to building fully dynamic pages. Programming languages like PHP, and more advanced server-side technologies, like mod_perl, enabled much more sophisticated web programming. While these technologies were significant enablers in terms of what could be done on the web, they still evolved around the concept of a page being generated upon load. Once it was loaded, one had to reload the entire page to refresh the content.
With the introduction of AJAX, it became increasingly important for ongoing communication between the server and client. You could all of the sudden have significant amount of API calls generated from an individual user on a given page. This was done in a ‘pull’ fashion, meaning that the client requested updates from the server at a given interval (or based on some action).
The modern way
To address this problem of latency and overhead, websockets was introduced as part of HTML5 and implemented in all modern browsers. Contrary to the traditional ‘pull’ approach (i.e. client asking server for changes), a websocket is as the name applies, a socket, where the the server can ‘push’ out changes to the client. Hence if there are no changes, there is no need for any communication. Also, since the client can communicate directly with the server without the added overhead of opening and closing connections, the application becomes a lot more responsive.
This is exactly how our own web application is built. The actual application is a static page that opens a websocket connection to the API. Once this socket is open, the web application can receive notifications from the server with changes. We still dispatch commands to the RESTful API, but notifications are pushed out from the server to the client using the websocket.
Not just for web-pages
While the most obvious use case for receiving updates using a websocket is via a browser, there are other use cases too. Perhaps you are writing some kind of monitoring tool that is monitoring changes to your architecture and fires off action based on this. In that case, you can speed up your application significantly by utilizing our websocket.
In our Python Library, pycloudsigma, we have built-in support for websockets. We even have a simple example how you can utilize this to monitor websocket activities with just a few lines of code. Here’s a quick demo of monitor_websocket_activity.py monitoring the actions triggered by the user input in the web-app.
Share this Post
- Manage Docker resources with Cgroups - May 12, 2015
- Docker, Cgroups & More from ApacheCon 2015 - April 30, 2015
- How to setup & optimise MongoDB on public cloud servers - March 24, 2015
- Presentation deck from CloudExpo Europe - March 17, 2015
- CoreOS is now available on CloudSigma! - March 10, 2015