Add a websocket server feature

[stan-dot]

For data streaming and visualization web frontends cannot use the STOMP format, and the most suitable streaming protocol is WebSockets.

See the implementation in the ViSR - plotting server https://github.com/DiamondLightSource/ViSR/tree/main/src/plotting_server

as well as davidia (though there the example is more complicated and not for live data): https://github.com/DiamondLightSource/davidia

The server state for now would encompass only a collection of websocket connections, and the RMQ url. Possibly a session holding logic could be introduced later if a race condition appears.

the race condition case

given a set of distributed processes - job scheduler, message bus, websockets relay service (this) and the client: if a client sends a job to the job scheduler, receiving a job_id in response and messages start to be emitted in the message bus and consequently in the relay service, the client either needs to be already subscribed OR only once getting a job_id would ask the relay server to listen for data for this particular job. Caching should be server side as the client can be easily disconnected, a pythonic solution might be needed, for instance redislite . JWT authentication might be necessary - I am not sure how would the auth gateway work for a WS protocol, which is not http.

Acceptance Criteria

• I can spin up a pod on a k8s cluster to listen to a given RMQ instance and listen for incoming WS connections
• web clients can connect to the server and

[callumforrester]

1. @keithralphs has worked on something similar
2. We need to decide if this repo is where this functionality belongs
3. I agree this is needed short term, long term should it be part of the supergraph? I believe that will support websocket subscriptions

[stan-dot]

3 we don't need to consider longterm to deliver this

2 the user story delivered (plotting ) will work if this functionality is here. that is one concerns addressed. what criteria do you have in mind @callumforrester and how much of delay do you expect this decision to cause. modular functionalities can be portable. I already thought that this is a closed aspect when you said it's not in the blueapi.

[callumforrester]

we don't need to consider longterm to deliver this

This library is designed to be stable and well-maintained with a focus on long-term goals. After considering your proposed solution, it seems better suited for a different context, so I'm going to close this ticket.

I suggest creating a monorepo for short-term prototypes aimed at delivering SWIFT functionality rapidly. You could even coopt i18-bluesky for that purpose.