STOMP over websockets vs plain STOMP. Which one is better?
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
STOMP (Simple Text Oriented Messaging Protocol) is a simple, text-based protocol designed for asynchronous message passing between clients and servers. It's particularly used in messaging applications where brokers handle the dispatch and delivery of messages. STOMP provides an interoperable wire format that allows STOMP clients to communicate with almost any message broker. It's designed to be easy to implement and provides a way to define text-based commands and headers, along with a body containing a message payload.
Understanding Plain STOMP
Plain STOMP operates over TCP or another reliable, ordered, streaming transport layer protocol. In this mode, a client communicates with a STOMP message broker by establishing a TCP connection and then sending STOMP frames formatted in a simple text-based protocol.
In this example, the client sends a CONNECT frame to initiate a connection with a STOMP broker, specifying the version and the virtual host it wishes to connect to. The message ends with a null byte (^@), which is the frame delimiter in STOMP.
STOMP over WebSockets
STOMP over WebSockets is essentially STOMP protocol implemented on top of the WebSocket protocol. This allows STOMP to run in web environments where direct TCP connections might be restricted or not feasible due to browser security constraints.
WebSockets provide a full-duplex communication channel over a single long-lived connection, which operates through a ws:// or wss:// URI scheme. STOMP messages are then framed as WebSocket messages rather than being streamed over TCP.
In this JavaScript example, a WebSocket connection is established, and STOMP frames are sent as WebSocket messages. This effectively encapsulates STOMP within the WebSockets protocol.
Comparing STOMP over WebSockets and Plain STOMP
| Feature | STOMP over WebSockets | Plain STOMP |
| Transport Protocol | WebSockets (ws://, wss://) | TCP (or similar) |
| Environment Compatibility | High (Web browsers, mobile apps) | Low (Requires direct TCP support) |
| Complexity | Higher (Needs WebSocket implementation) | Lower (Direct TCP connection) |
| Security | Built-in secure variant wss:// | Depends on underlying transport security measures (e.g., TLS over TCP) |
| Latency | Potentially higher due to framing | Typically lower as it's more direct |
| Scalability | High with web-based clients | Depends on network environment |
Which is Better?
The choice between STOMP over WebSockets and plain STOMP largely depends on the application environment and specific use cases:
- Web Environment: STOMP over WebSockets is generally better for web browsers and environments where WebSocket support is built-in, providing a good balance of features with security (
wss://). - Non-Web Environment: For server-to-server communication or when both client and server environments support direct TCP connections, plain STOMP will typically perform better with lower latency and complexity.
- Security Concerns: While both support secure transmissions, WebSockets’ native
wss://support in browsers simplifies secure implementations in web applications. - Scalability in IoT and Mobile Applications: STOMP over WebSockets is preferable due to the wide availability of WebSocket support in these platforms and the higher level of firewall traversal capability it offers.
Conclusion
The decision between using STOMP over WebSockets versus plain STOMP should be driven by the application's deployment environment, performance needs, and security requirements. For browser-based and mobile applications, STOMP over WebSockets offers an efficient and compatible solution. In contrast, for backend systems where direct TCP connections are possible, plain STOMP might be a simpler and faster alternative.

