Exposing the SSE endpoint

To expose the SSE endpoint, we need a REST controller that is autowired with the TemperatureSensor instance. The following code shows the controller, which utilizes RxSeeEmitter:

@RestController
public class TemperatureController {
   private final TemperatureSensor temperatureSensor;                // (1)

   public TemperatureController(TemperatureSensor temperatureSensor) {
      this.temperatureSensor = temperatureSensor;
   }

   @RequestMapping(
      value = "/temperature-stream",
      method = RequestMethod.GET)
   public SseEmitter events(HttpServletRequest request) {
      RxSeeEmitter emitter = new RxSeeEmitter();                     // (2)

      temperatureSensor.temperatureStream()                          // (3)
         .subscribe(emitter.getSubscriber());                        // (4)

      return emitter;                                                // (5)
   }
}

The TemperatureController is the same Spring Web MVC @RestController as before. It holds a reference to the TemperatureSensor bean (1). When a new SSE session is created, the controller instantiates our augmented RxSeeEmitter (2) and subscribes to the RxSeeEmitter subscribers (4) to the temperature stream referenced from the TemperatureSensor instance (3). Then the RxSeeEmitter instance is returned to the Servlet container for processing (5).

As we can see with RxJava, the REST controller holds less logic, does not manage the dead SseEmitter instances, and does not care about synchronization. In turn, the reactive implementation manages the routine of the TemperatureSensor's values, reading, and publishing. The RxSeeEmitter translates reactive streams to outgoing SSE messages, and TemperatureController only binds a new SSE session to a new RxSeeEmitter that is subscribed to a stream of temperature readings. Furthermore, this implementation does not use Spring's EventBus, so it is more portable and can be tested without initializing a Spring context.