For most applications you’re going to build, HTTP communication is a no-brainer. However, as a system grows, a real-time communication between client and server becomes a requirement and the developers apply a websocket-based solution.
But websockets not only provide push notification from server to client, they also create a handful of opportunities to follow good practices and make the whole system more reactive.
Disclaimer: yes, designing your system without HTTP communication is difficult and I believe it to be inherent difficulty of designing a reactive, extendable system. I would probably never do this on production unless widely-discussed with stakeholders, but this article is not about providing a solution, but rather starting a discussion.
What does reactive mean?
The famous reactive manifesto favors responsive, resilient, elastic and message-driven application design as a solution for ever-growing requirements about performance, stability and functionality.
To put it briefly, a reactive application can respond to changing environment and therefore be well-prepared for both expected and unexpected real-world conditions. It turns out, that websockets can help achieving it.
More generic point of view
Let’s take a step back and try to define what are client and server in a regular web app:
- a server is a long-running application responsible for persisted data, it can talk to many clients
- a client is an application of constrained lifetime which serves the purpose of allowing the user to read and write data provided by the server, it can talk to server
Server and client are actually only names for applications of specific purpose. What happens if we stop considering them somehow special and try to design each of them as just another node in the system?
- a server becomes a long-running application responsible for persisted data that can both receive and send messages
- a client becomes a short-running application that can both receive and send messages
One should be enough
What tool is a typical solution of web-based messaging? Websockets, of course. And, contrary to Windows Apps Team, I argue that this very protocol should be the one and only for creating enterprise (and fancy) web applications, here’s why:
- first and foremost, it enables both-ways communication among any group of applications (not only client and server)
- it greatly simplifies the architecture – since you already have websockets in your application, what’s the purpose of a different communication protocol?
- it enforces message-based communication and favors event driven reasoning, thus make your application aligned with the reactive way
- deprives your web client from “special” status, it becomes a just another node in the system
- removes a great deal of abstraction on server side and makes communication more direct
I am aware that apparently HTTP and websockets, as protocols, serves different purposes. I disagree with it and claim that advantages of HTTP do not origin from its inherent features, but rather from its status as a default solution.
Not that once you shift your reasoning from client-server to actor system like Akka.NET or similar, it turns out that websockets actually should be the default way of communication for enterprise systems and my private interactive diagram application can be an example of a rich, websocket-based web app with no HTTP at all.
So, if websockets can do everything HTTP can, why do we use HTTP anyway?