WebSockets

1 / Real-Time Communication

WebSockets appeared in my work when HTTP request-response cycles were insufficient for the interaction model. In both Conclave and Foundry, users needed to observe agent activity as it happened — waiting for a complete response before rendering was not acceptable for multi-turn agent debates or graph evaluation progress.

2 / STOMP Broker Coordination

In Conclave, WebSocket connections were layered with the STOMP messaging protocol over Spring Boot. This provided topic-based message routing — each debate session had its own subscription channel, and clients received incremental turn-by-turn updates as models produced output. Managing stateful WebSocket connections across multiple concurrent debate rooms required careful session lifecycle handling and cleanup on disconnection.

3 / Challenges

The most persistent challenge with WebSockets was deployment configuration. When deploying Trajectory to AWS behind Nginx, the reverse proxy needed explicit upgrade headers for WebSocket connections. Missing or misconfigured `Upgrade` and `Connection` headers caused silent connection failures that were difficult to diagnose because the initial HTTP handshake succeeded while the protocol upgrade silently failed.