TECHNICAL OVERVIEW

Web Sockets for Node.js Applications

Showing off his expertise, Brett Cizmar, a software developer at Acro Commerce, dives into a subject that few people outside of our engineering department know much about.

Understanding web sockets and knowing when and how to use them makes all the difference when designing web applications. Having a development partner like Acro Commerce, whose stable is full of thoroughbred developers like Brett, means the difference between having a development project with a so-so outcome and one with all of the bells and whistles your customers demand.

What Are Web Sockets?

Web sockets are a technology that allows for two-way communication between server and client. They use what is known as a "full duplex" communication channel, which means that the server or client does not need to wait for a message before sending the next one. Because this data can be sent and received asynchronously, web sockets are a great tool for any web experience that requires a lot of interactivity and feedback with real-time data.

Web sockets allow your application to respond in real-time without page reloads when conveying data changes. We can integrate these solutions into our backend systems and create a front-facing web application on a new page on your website to relay a curated experience specific to your business needs.

How Do We Use Web Sockets?

A common method for creating a web application with web sockets is using a Node.js backend and Socket.io. 

Node.js allows us to run JavaScript on the server outside of the browser. Our Node.js application can then run web sockets through an abstraction layer, making it easier for us developers to build our business logic on top of it. A popular solution for this is Socket.io. 

Socket.io is a library that provides a toolkit to implement web sockets easily for a given web application. Instead of needing to build much of the redundant “scaffolding” around some of the most common use cases for web sockets, socket io provides a straightforward library to begin passing data around.

Here are a few useful features it provides:

• Broadcasting data globally
• Broadcasting data to rooms
• Having clients easily join or leave rooms
• Sending data privately to an individual user

Why Web Sockets Over Other Solutions?

As with many things in web development, there are many solutions to any given problem. For live updates, you might also consider simply polling the data from the client on some interval or event trigger. One cross-analysis we can perform is utilizing webhooks from an e-commerce provider and giving live updates to new product orders to show the volume a storefront is moving in real time to your customers.

When you use web sockets, new data comes through on the consumer side you receive it. When you poll for data (for example, using a RESTful API), you're asking for data when there isn't necessarily any new data available. This can be a waste of resources for both the client and your server. Polling services are also only as fast as the interval you poll at. Usually, considerations need to be made, and this data will sometimes only be delivered between large time gaps. On top of this, you will likely then need to build a "queue" system on your backend to fulfill pending data that needs to be sent out. With web sockets, you don't need to worry about these constraints and can simply deal with the data right as it becomes available.

Planning To Use Web Sockets

Typically, a web socket service will run alongside a RESTful API for most web applications. Before programming the backend code, you should carefully consider how you want to split up your processes or where you might want to have a RESTful and web socket path for data to flow. For socket.io, you should also consider the scope in which data will be passed. 

In socket.io, anytime we send data we call this an “emit”. Some situations may call for emitting data globally to all connected consumers, and some may call for utilizing socket.io rooms. 

• A straightforward example of this is literally a chat room. In this case, you would break down receiving messages scoped per room.
• A more abstract example might be a finance application where real-time price updates for a company should only be sent to people viewing that company's trading data. Discerning the scope for data emitting is an important consideration before getting too far into socket.io development.

One Example: Real-time Data Analysis

When you need a visual representation of your data and a curated solution for that display, web sockets work great in tandem with front ends, leveraging all sorts of different fancy ways to display that data. 

Web applications leveraging three.js and Socket.io could render complex data in an interesting visual way using WebGL. These types of solutions are great for when you have a complex set of data and are looking to relate meaningful heuristics to a customer or as an analytic feature for your team.

A few examples of potential curated web socket solutions for your business:

• An internal dashboard where you can see real-time metrics on purchases, logistical information for shipping, or other content updates related to the product.
• Perhaps your business has unique customer interfacing requirements. Any potential interaction could be relayed in real-time through a web application. This could be passing documentation back and forth in a private session for a consultation service. Or if a business is required to work in tandem with a customer through a unique series of steps that need to be updated without page reloads.
• An IoT company offers products that need remote access to your company's central service. Your customers need an interface to interact with these services and see changes in real-time through a web application.

When NOT to Use Web Sockets?

While web sockets are fast, bidirectional, and allow us to easily perform real-time updates, there are situations where non-WS protocols are more suitable. 

With web sockets, we often lose rigidity in structure and intent when it comes to the way we pass data. For example, while I might feed data into an application with web sockets, I usually prefer to POST data back to a RESTful API to update something. This is because we have much better standards surrounding HTTP methods and the intent behind what we are doing when we make these requests.

Documentation then becomes clearer on what is happening. Often, with web sockets, a modern backend framework can sometimes only take you so far. The organization and flow of the output/input of this data can sometimes become complex and difficult to manage, especially in large teams.

Web sockets are excellent when you need real-time data, especially when there is a large volume and consistent flow of such data that needs to be represented in some way immediately on a client-side application without page reloads. That being said, web sockets should be used thoughtfully and with consideration for the necessity of backend services that must be built around them.

Want to know more about the web development tools we use?

Our teams have a large cache of world-class and best-in-breed tools at our disposal.
Fill in the form below, and one of our subject matter experts will reach out to talk to you personally.