Why Choose Server-Sent Events (SSE) Over WebSocket: Comparison, Benefits, and Spring Boot Implementation

In many projects real‑time communication is required, but when the client only needs to receive messages, using a full‑duplex WebSocket can be overkill. The article introduces Server‑Sent Events (SSE) as a lightweight alternative and contrasts it with WebSocket and polling.

Comparison table highlights: SSE is a one‑way, long‑connection protocol based on HTTP/1.1 or HTTP/2, with low server and client overhead, automatic reconnection, and broad firewall compatibility. WebSocket offers bidirectional communication but incurs higher server load and requires custom reconnection logic. Polling is simple but generates high bandwidth consumption and lacks real‑time guarantees.

Why abandon WebSocket for simple push scenarios: authentication handling, complex logging, connection management, and the need for periodic message sending make WebSocket heavyweight when only server‑to‑client pushes are needed. SSE integrates with Spring Boot without extra dependencies and requires only a few lines of code.

Code example – AsyncTaskExecutor configuration (required for production‑grade async support):

@Configuration
@Slf4j
public class WebMvcConfig implements WebMvcConfigurer {
    @Bean(name = "customAsyncTaskExecutor")
    public AsyncTaskExecutor customAsyncTaskExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        int corePoolSize = Runtime.getRuntime().availableProcessors();
        int maxPoolSize = corePoolSize * 2;
        int queueCapacity = 500;
        executor.setCorePoolSize(corePoolSize);
        executor.setMaxPoolSize(maxPoolSize);
        executor.setQueueCapacity(queueCapacity);
        executor.setThreadNamePrefix("AsyncExecutor-");
        executor.setWaitForTasksToCompleteOnShutdown(true);
        executor.setAwaitTerminationSeconds(60);
        executor.initialize();
        return executor;
    }

    @Override
    public void configureAsyncSupport(AsyncSupportConfigurer configurer) {
        configurer.setTaskExecutor(customAsyncTaskExecutor());
        configurer.setDefaultTimeout(5000);
    }
}

Code example – SSE endpoint that streams online‑user count every 5 seconds:

@PreventDuplicateSubmit
@PreAuthorize("@permission.checker('monitor:online-user:list')")
@GetMapping(value = "/user-activity-sse", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public Flux
streamUserActivitySSE() {
    // Create a Flux that emits a value every 5 seconds
    return Flux.interval(Duration.ofSeconds(5))
        .flatMap(seq -> Mono.fromCallable(onlineUserService::getUserActivityNum)
            .onErrorReturn(0));
}

The article also shows the front‑end effect (a GIF) and discusses a real‑world case where polling was used for an ID‑card scanner integration, noting that SSE would have been a cleaner solution.

Finally, it concludes that both WebSocket and SSE have their places; the choice depends on whether bidirectional communication is needed, and many scenarios such as notifications can be efficiently handled with SSE.

References to the original Juejin article and the Git‑hosted source code are provided for further reading.