Web Evolution: from CGI to Websockets (and how it will help you better monitor your cloud infrastructure)

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

PHP Logo
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.

As the web evolved, we entered into the AJAX/Web 2.0-era of the ’00s, web-pages became much more dynamic and responsive. No longer did you need to reload the page to update the content on the screen. All you needed to do was to fire off some JavaScript actions. Many AJAX-pages were still powered by PHP, but with the introduction of client-side JavaScript, could be made a lot more dynamic.

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

As we entered into the ’10s, it was common for web-pages to be completely divided between the front-end (HTML/JavaScript/CSS) and the back-end (Ruby on Rails, Django etc), which was often hosted on different servers. The way the front-end communicated with the back-end was via an API. The front-end was more or less static. With this trend, making API calls to the server became a significant bottleneck. If you had to fetch ten different things from the server, it often meant that you needed to do ten different API call, with each call carrying a significant overhead and latency.

The modern way

HTML5 LogoTo 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.

Download WordPress Themes
Download WordPress Themes Free
Download Premium WordPress Themes Free
Download Nulled WordPress Themes
online free course
download karbonn firmware
Download Premium WordPress Themes Free
udemy paid course free download