Spring Boot WebSocket with STOMP — Step-by-Step Setup

Raw WebSocket gives you a bidirectional pipe and nothing else — no routing, no subscriptions, no message types. STOMP is the sub-protocol that adds these messaging semantics, and Spring Boot wires everything through @EnableWebSocketMessageBroker.

The three-piece setup:

• A configuration class where you register the WebSocket endpoint and define destination prefixes — /app for messages that hit your @MessageMapping controllers, and /topic or /queue for the broker's pub/sub destinations
• Controller methods annotated with @MessageMapping that handle incoming messages exactly like REST controllers handle HTTP requests; @SendTo or @SendToUser determines where the response goes
• SimpMessagingTemplate for pushing messages from anywhere — background jobs, event listeners, scheduled tasks — without a client initiating the call

The prefix routing distinction — the most common bug source:

• When a client sends to /app/chat.send, Spring strips /app and routes to @MessageMapping("/chat.send"); the response annotated with @SendTo("/topic/public") goes to the broker and fans to all subscribers
• If you accidentally send directly to /topic/chat.send, the message bypasses your controller entirely — no business logic, no validation applied; this silently works from the client's perspective

Production requirements:

• Add .withSockJS() so clients behind proxy-blocked networks can still connect via fallback transports
• Replace enableSimpleBroker() with enableStompBrokerRelay() pointing at RabbitMQ — the simple broker is a ConcurrentHashMap in one JVM that doesn't survive restarts and doesn't span multiple server instances

I recommend the external broker relay from day one for any service with more than one instance, and @SendToUser for any message that contains data private to a specific user.