Achieving Real-Time Functionality in a Web App — the ‘Right’ Way

Today, there are many scenarios in which we expect real-time (or near real-time) functionality from our web applications. Often it is not even a conscious expectation—but instead is a more subtle enrichment of user experience that many take for granted. When I encounter this demand in my web development work, I take a step back to consider the ‘right’ solution for that particular context. This is because there are numerous ways of achieving a real-time experience (or the illusion of it)—be it through programmatically re-executing data queries or by opening a steady two-way data stream via a WebSocket subscription; or anything in between. Making the ‘right’ choice requires that a developer weigh the application’s needs against the performance expenses associated with the various data acquisition methods. 

Perhaps the most straightforward way to keep the client (your users) seamlessly up to date with your backend is through intermittent polling. For example, an investment application might allow its users to track their favorite stock prices by re-executing a query of the stock data every 10 seconds, perhaps even re-rendering some corresponding charts or graphs with that cadence as well. This approach can and does gracefully cover many use cases and provides a predictable, relatively responsive experience. The downside: polling can be expensive—especially when you are repeatedly querying for large, complex objects for which most of the fields change infrequently.  

A more holistic approach to keeping the client in sync with your backend is using a subscription: a means of bidirectional communication that allows information to flow freely without needing to re-query the database. This persistent connection is usually achieved by communicating via WebSocket (WS) rather than the standard HTTP transport. The power of subscriptions lies in their ability to communicate updates to individual fields as they occur in the database. For this reason, the approach proves very efficient in the case of small, incremental changes to large data objects.  In addition to their efficiency, subscriptions bring true real-time functionality to the table. In cases where your application demands new information as soon as it is available (think instant messaging), the subscription approach provides what is perhaps the very best sustained low-latency solution.  

On the other hand, if your application only needs an update every 5 minutes, it is less expensive to re-initiate an HTTP connection with each update than keeping a WS connection open for that duration when no immediate updates are required or available. The decision between the two protocols always includes weighing the two costs in your specific use case. Option one is the cost of keeping an existing WS connection open (in which case the client constantly receives information—albeit only the response data and a very small header). The second option is the cost of establishing a new HTTP connection (which requires that the client send large headers with the request and receive large headers back with the response). Whatever the best solution may be for your web application, adding real-time functionality can significantly enrich your end-user’s experience and inspire confidence in the app.