Something that's important to understand is the flow of messages. So far, we have seen messages sent from the website into the comments service, stored into a MongoDB database, and then forwarded to our chat service.

At this point, we are trying to onramp these messages to WebSockets. But what does that mean? A WebSocket is a very lightweight, two-way channel between a web page and the server. WebSockets, on their own, don't dictate much about what travels over this thin pipe, but one thing is for certain--​each web page, when connected to a server, has a separate session.

Spring WebFlux provides an API that lets us hook into this WebSocket-oriented session, whether to transmit or receive. But no WebSocket session is immediately linked to another WebSocket session. If we were using Spring Framework 4's WebSocket API, we would be leveraging its most sophisticated Messaging API. This API was born in Spring Integration, and is the same concept found in Spring Cloud Streams. Spring MVC comes with a built-in broker to help bridge messages between different sessions. In essence, a message that originates in one WebSocket session must be transmitted to the broker where it can then be forwarded to any other WebSocket session that might be interested.

With Spring WebFlux, we have no such Messaging API, no such broker, and no higher level constructs such as user-based messaging. But it's no big deal! We can fashion it ourselves--using the Spring Cloud Stream tools we are already familiar with.

Through the rest of this chapter, we will chain together these streams of messages, and it will be most elegant.