Lagom could support SSE as an alternate to WebSockets for streamed message bodies.
The approach to supporting SSE should be generic enough to allow handling any message body as a stream, not just SSE (eg, multipart/form-data). Also interesting is that SSE doesn't have to be limited to just responses, the request body could use SSE (there's nothing in HTTP that says the server has to consume the request message before sending the response message, you could have bidirectional SSE streaming, of course, this wouldn't work with a browser, but it would work between Lagom services).
We should investigate whether Lagom's existing protocol negotiation features could be used to actually decide which protocol gets used.
Hi!
I'm just commenting as an end-user. To follow the existing behavior a suggestion is that if you have a ServiceCall< NotUsed, Source,?> > SSE should be default (since you are only specifying a "one way" channel), if the first type param is set to a Source I would expect to get the websocket protocol.
Would of course also be nice to be able to set it explicitly, maybe with Method.WS / Method.SSE
Is the default of SSE in one way communication server -> client expected for an upcoming release, or has this already been implemented? I haven't found additional information on the website. Thanks.
@kimgysen this has not been implemented yet (issue is still open) and the Lagom team at Lightbend currently has no plans to implement this soon. We'd welcome a pull request if you're interested in implementing it, but I would also suggest discussing your overall approach with the team first.
Most helpful comment
Hi!
I'm just commenting as an end-user. To follow the existing behavior a suggestion is that if you have a ServiceCall< NotUsed, Source,?> > SSE should be default (since you are only specifying a "one way" channel), if the first type param is set to a Source I would expect to get the websocket protocol.
Would of course also be nice to be able to set it explicitly, maybe with Method.WS / Method.SSE