Could SSE solve Meteor performance issues out of the box?

core
1

So today I found out about SSE:

With server-sent events, it’s possible for a server to send new data to a web page at any time, by pushing messages to the web page. These incoming messages can be treated as Events + data inside the web page.

So if I get this correctly the client could just listen for events that the server sends when needed instead of being connected to the server constantly.
I think, if we implemented this in Meteor, it could significantly reduce performance issues out of the box. This is because subscriptions are mostly what SSE describes, so it seems to me to a great fit.

Now, the problem we have with this is:

Warning: When not used over HTTP/2 , SSE suffers from a limitation to the maximum number of open connections, which can be especially painful when opening multiple tabs, as the limit is per browser and is set to a very low number (6). The issue has been marked as “Won’t fix” in Chrome and Firefox. This limit is per browser + domain

So we would have to implement HTTP2 in Express (using a community package as it is not currently supported out of the box) or go directly through the node:http2 module (probably a better approach).

Just something to consider.

What are you thoughts?
@nachocodoner @italojs

2

The big disadvantage of SSE over WebSockets is that the former only goes one way. So all communication from the client to the server would have to be sent via a different channel, which means there are at least two forms of authorization and session tracking. Especially the latter may be tricky, as currently Meteor can rely on the fact that the mergebox doesn’t have to be synchronized between instances.