Readers who are familiar with the servlet-based WebSocket module may notice that there are a lot of similarities in the design of both modules. However, there are a lot of differences as well. As we may remember, the main disadvantage of the Spring WebSocket module is its blocking interaction with IO, whereas Spring WebFlux offers fully non-blocking writes and reads. In addition, the WebFlux module offers better streaming abstraction by employing the Reactive Streams specification and Project Reactor. The WebSocketHandler interface from the old WebSocket module only allows to process one message at a time. Also, the WebSocketSession#sendMessage method only allows sending messages in a synchronous fashion.

However, there are some gaps in the integration of the new Spring WebFlux with WebSocket. One of the critical features of the old Spring WebSocket module was good integration with the Spring Messaging module, which allowed the use of the @MessageMapping annotation in order to declare the WebSocket endpoint. The following code shows a simple example of the old, Web MVC-based, WebSocket API with the use of annotation from Spring Messaging:

@Controller
public class GreetingController {

   @MessageMapping("/hello")
   @SendTo("/topic/greetings")
   public Greeting greeting(HelloMessage message) {
      return new Greeting("Hello, " + message.getName() + "!");
   }
}

The preceding code shows how we could use the Spring Messaging module to declare a WebSocket endpoint. Unfortunately, such support is missing for WebSocket integration from the WebFlux module, and in order to declare complex handlers, we have to provide our own infrastructure.

In Chapter 8, Scaling Up with Cloud Streams, we are going to cover another powerful abstraction for duplex messaging between client and server, which may be used ahead of simple browser-server interaction.