from CGI to Websockets

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 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. You enter your email address and press ‘submit,’ then see a separate page that processed the data. This 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, they still evolved around the concept of a page generation upon load. Once 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 more dynamic.

Introducing AJAX

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. We do this 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 we push notifications out from the server to the client using the websocket.

Not just for web-pages

While the most obvious case for receiving updates using a websocket is via a browser, there are other cases too. Perhaps you are writing a 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 monitoring the actions triggered by the user input in the web-app.
For more information on our services, check out our Features.


About Viktor Petersson

Former VP of Business Development at CloudSigma. Currently CEO at WireLoad and busy making a dent in the Digital Signage industry with Screenly. Viktor is a proud geek and loves playing with the latest technologies.