Welcome back! It’s been a minute since I explained something most of you probably know better than me 🙂. For WebSocket, I knew very little before I did my research. I understood that it was widely used and that it was a tool for two way communication, but had no knowledge beyond that. So let’s get right to it!

The Evolution of the WebSocket

History time! What came before WebSocket? HTTP of course! HTTP is a stateless request-response mechanism that stands for “hypertext transfer protocol” and it worked well for many years and is still a great option for certain use cases today, think websites, HTTP is a great fit for this use case. The request/response mechanism was basically used for the same thing WebSocket is used for today, albeit some use cases have far outgrown HTTP. If the connection dropped between the request/response with HTTP, it wasn’t a problem. You could restore communication at any point thanks to its stateless nature. Back in the olden days, there was only a need for dealing with text docs and a limited amount of additional assets, so HTTP was all that was needed.

Evolution is inevitable when it comes to the world of tech, and applications quickly evolved beyond what HTTP could offer. Developers needed more because applications were shifting towards real-time implementations, and latency from the high frequency of request/response was making it impossible to achieve the real-time communication needed. Thus came long polling which allowed the TCP connection to stay a little longer than HTTP, but this was really just a temporary bandaid rather than a full solution. There were still issues with latency and overhead… so Hello World, WebSockets were born!

Before WebSocket was called WebSocket it was referenced as TCPConnection in the HTML5 specification, as a placeholder for a TCP-based socket API. WebSocket came to be in June of 2008 when Micheal Carter, a tech entrepreneur, led discussions around the protocol that would become WebSocket. What’s behind the name? Carter and a fellow by the name Ian Hickerson coined WebSocket in a chat room. One could even say they named the two way communication protocol using a two way communication tool (see what I did there)! By the end of 2009, Google shipped full support for WebSocket with their Chrome 4 release and it became widely available through multiple browsers by 2011. Even iOS and Android support WebSocket as of 2013, so there are really endless possibilities when using the protocol.

WebSocket: To Transport or To Protocol

So now that we have the history, let’s break down the technology. WebSocket opens a bi-directional communication path between a server and client. This path is persistent which is a fancy way to say continuous and in both directions, so there is very low latency and high efficiency within the communication path. You don’t have to worry about individual responses and requests, instead it’s like the infinite loop that is always on as long as parties have agreed to an initial “handshake” (which is actually a response/request HTTP call, meaning there is a touch of old school thrown in with the new).

One article I found described WebSocket as a thin transport layer built on top of a TCP/IP stack. They also mentioned that some refer to WebSocket as a protocol (i.e. me) while some refer to it as a transport. The author says transport is more accurate and I actually found this very interesting because I never had heard it called a transport before and will call it a transport going forward in my blog. I don’t want to divulge too much into this argument, but take a read for yourself and then let me know what sounds more accurate to you in the comments! Side note: if you want a really in depth read from someone with a technical background on WebSocket, this article is overall an excellent resource and I found it to be the most in-depth resource out there.

There are three main interfaces when it comes to WebSocket:

WebSocket-primary interface for the connection of the server to send/receive messages
CloseEvent-event when a WebSocket connection closes
MessageEvent-event when a message is received from the server

WebSocket has provided a standardized way for client applications and browsers to talk to servers without tedious requests every time. Work smarter not harder is what I always say and WebSocket lives by this code!

WebSocket Use Cases

The main purpose of WebSockets has already been stated: a communication path from your application to your server. Here are some more specific ideas for using WebSockets that follow the server to app path:

1. Social feeds, news feeds, and chat rooms!
2. Games that are for multiplayer
3. Collaboration tools like Dropbox or tools for collaborative coding
4. Location based apps (hello Find My Friends- is this stalker status or cool? Thoughts?)
5. E-learning- well that seems relevant in 2020!
6. Many others! Anything you can think of that I missed?

Data visualization is another use case for WebSockets, again due to the real-time nature that can be needed for data visualizations, like say, for maps that show real-time weather data so that you always know whether to rock your flip flops or your snow boots (if you live in Colorado like me then you wear flip flops regardless because we are hardcore here)!

Review WebSockets with Actual Developers 🙂

Next week, the HarperDB team is putting on one final virtual event to close out 2020. If you want to go deeper into WebSocket and what it can do for you, you should RSVP! We will be joined by Casne Systems Engineer, Carl Argabright, to chat about all things WebSocket and explore a case study using WebSocket as the fastest method for collecting high resolution data for analytics. The event will be on December 8th (that’s only FIVE days away!) at 5:00pm PST. (No worries if you can’t make it live, if you RSVP you’ll receive a recording of the event afterwards!)

If you prefer written tutorials and content, Ethan Arrowood just wrote this excellent tutorial on HarperDB and WebSocket. You can check out the HarperDB WebSocket Client in the HarperDB Developer Marketplace. As always, send me feedback and tell me what I missed when it comes to the wonderful world of WebSocket. Or if you have suggestions for what I should cover next in this series please LMK!