Subscriptions through SSE

[thelinuxlich]

To keep things simple, as of today most browser support HTTP 2, so SSE doesn't have those disadvantages of the past and can replace Websockets anywhere you aren't building a FPS-shooter on the browser :)

So it's a simpler architecture and built upon HTTP already. Some GraphQL projects are already adopting SSE as the standard for subscriptions, like graphql-yoga for example.

What do you think?

[ecyrbe]

Hello,
Thank you for raising a question,
suscriptions are out of scope for zodios, whatever technology behind it (sse, websockets, long pooling, etc)
Indeed, zodios is focused on Rest. And Rest contract is at the center of Zodios design.
So any suscription technology can be added alongside zodios.

[thelinuxlich]

I'd say if you aren't using the CRUD plugin, Zodios seems much more centered around actions than resources. The only thing I see missing in Zodios right now for SSE is some property so the client can understand it's streamable and invoke it with the proper headers, although that could be done by convention(if the action defines the sse header)

[ecyrbe]

I a reminder, zodios is a full stack toolbox. So this means, if doing notifications, zodios should add support for it in @zodios/express and future packages like @zodios/fastify, @zodios/nestjs.

Now on my point of view as a library maintainer, doing any kind of notification support would be out of my reach. here is why :

On the backend part:
Indeed, notifications done right on server side is a really hard problem to solve. That's why there are platforms dedicated to doing notifications and usually they involve really complex systems to add resilency, persistance, scalability, shared queuing, etc..
So adding sse is really out of the goal for @zodios/express.
I don't have the man power, the knowledge and will to tackle this. This would mean a complete new class of issues opened in an area where i don't have any expertise and no ability to handle the load of issues that will arise due to bugs, performance issues, scalability issues, tooling issues, inspectability issues etc...

On the frontend part:
SSE has web support throught EventSource, This is a streaming technology not supported by axios and axios is at the core of zodios client.
Adding SSE support would mean adding a streaming interface, on top of EventSource to add typesafety support. So it should be better implemented as it's own project and don't need to be implemented in zodios package familly.

My point of view :
Adding anything to support notifications, without it being just a toy is out of what zodios was meant to be. I see this feature as a completely separate project and so don't need to rely on zodios on doing so.

[thelinuxlich]

Agree it should be a separate plugin for @zodios/express and then a thin client consuming the API definition to provide typesafety through EventSource. When the need arises I might start this plugin.

[thelinuxlich]

That said I disagree on the added complexity around scalability when using SSE...the problems the user might face are the same for plain HTTP, solved by load balancing, caching, etc, with the advantage of not needing a separate socket server like Websockets, it's just HTTP.

[dejay-at-upstart]

That said I disagree on the added complexity around scalability when using SSE...the problems the user might face are the same for plain HTTP, solved by load balancing, caching, etc, with the advantage of not needing a separate socket server like Websockets, it's just HTTP.

I'm late to the party, but isn't it still true that most load balancer configurations have more complex configuration, scaling, and orchestration concerns when you have to support keep alive, persistent connections, and session stickiness? I haven't used SSE in that topology before, and am not sure how caching would even be handled for proxies that use URL and HTTP headers as the primary mechanism for cache key identification.