What to Consider Before Implementing Your Own WebSocket Protocol

Occasionally I get asked by front-end developers why they should bother with an event broker when their app can talk directly to their server via WebSocket. It’s true of course, you can do that; like most design decisions it comes down to where you want to invest your technical resources. I think the first things to consider are level of effort and time to market: are you prepared to design and implement a communications protocol? Is it worth it? It seems so simple at first. You quickly get something that works decently, and mistakenly think you’re in the clear, only to see issues gradually crop up requiring more and more capabilities. To get a robust, production-grade solution you need to put in place several capabilities:

• Session tracking, state-machines, and session notifications
• Session heartbeats, liveness
• Transport sequencing and correlation
• Data framing, acknowledgment, and negative ack
• Sequence control – fragmentation, redelivery, resequencing
• Flow control, throttling/buffering
• Authentication and security

You won’t need all of of those capabilities from the beginning, of course, but the more sophisticated your application becomes, the more of that work you’ll need to do. One of the most insidious and costly elements of this is the gradually increasing friction that comes with supporting an ad hoc, unplanned and poorly specified communications protocol in full urban sprawl. Protocol designs have notoriously long effects; without proper planning there is a high risk that early decisions make important capabilities prohibitively difficult to implement later.

Simultaneous Tracking of State at Several Levels

What makes communication protocols so difficult is that they inherently require tracking state at several levels. You need to track session state and liveness, packet framing, transmission and sequence, and higher order message boundaries, transactions, security. That’s a lot of concurrency, and all these activities need to be interleaved together to service I/O while tracking session state, handling control messages, data messages and dispatching in real time—all while avoiding protocol mistakes where both sides deadlock expecting each other to send something. Have a look at a few of the open protocol standards out there to get a sense of what it entails.

So, coding your own protocol is nothing to be taken lightly, but in addition to these coding concerns there are wider architectural considerations. What happens when you want to add events from another service? Or several of them? Do you refactor them to use your home-grown protocol, or will it require another protocol? How are the services communicating with each other? How many WebSocket connections will you be juggling?

Scaling to Accommodate Sources and Subscribers

One of the great strengths of an event broker and event streaming for event-driven applications is how simply you can scale up the connectedness of your client applications while keeping session management overhead constant. Without a broker, to add more data sources you’ll add more socket sessions and whatever security they require. You add reconnect logic, session notifications, and a layer of session collection management on top to manage and coordinate all these different sessions. The management overhead for all those sockets will top out very quickly because it just doesn’t scale well. And you sure hope those protocols don’t interact with each other in bad ways that introduce bugs!

Flexibility to Add Features Faster

Now compare that to communicating to services via a single event broker connection. Adding notifications from a new service reduces down to two steps: subscribe to the channel, and handle the event. That’s it! When you reduce the amount and complexity of code that dramatically, you can focus on building and rolling out new features. You can add product updates, adverts, recommendations, and live chat into your clients without adding any new connections. On the backend, add logging services, business intelligence, fraud detection or other analytics by simply ‘wiretapping’ these streams with zero modifications to the original source or recipients of those events.

Conclusion: Event-Driven Architecture is Better Than Point-to-Point Interactions

The secret to these advantages is the decoupling that occurs when you  introduce asynchronous eventing. If your clients were tethered to one server with one bespoke protocol, you have limited options, but when you use eventing and streaming, you have more. Of course, there are cases at the very simple end of the feature spectrum where a WebSocket connection is the right choice; but it’s worth a look further to make sure it’s simple and bounded — and absolutely going to stay that way. Because the downsides of tight-coupling, lack of scaling, and high development overhead are significant and steep. Choosing a simple, open event broker like Solace PubSub+ Event Broker avoids them while providing greater architectural flexibility.