Websocket transport can be opt-in

[aogaili]

Currently, Helene defaults to web socket and falls back to HTTP/REST. This is not always needed by default and it results in a stateful client connection that creates pressure on the server when scaled.

Ideally, a configuration option is provided to control this behavior on client startup, and the ability to initiate a socket connection later per page or as a singleton. We could also have an option to change the default method RPC layer (rest vs. web socket) if the web socket is globally initialized or pass an option per method call to control whether we can the call to be done using which transport.

This is important because many application is stateless, and doesn't require web sockets, so having a thin wrapper around REST API as RPC would be useful for developer ergonomics.

[leonardoventurini]

I am trying to come up with the right API for that.

A few use cases I've seen are:

• HTTP always (SSE, perhaps even polling)
• WebSocket always (need to have persistent connections/know users are online)
• HTTP until turning either SSE or WebSockets on.
• WebSockets until having to revert to HTTP for whatever reason.

Perhaps we can come up with an automatic WS -> HTTP switch once there are no event subscriptions on a given page or something like that.

Will keep researching this. Thanks!

[aogaili]

Yes, I think this important to get this specific API right.

You could have a case where in one page the method calls are http/rest, and you still have socket connection to receive push from a server and refresh.

I was thinking of app global default config with ability to override per page and even per method. And when in http in a page, there should be a way to open socket easily and migrate a method call to a socket if needed.

The ideal API would have reasonable defaults yet give develoeprs control when they one.

[aogaili]

Ideally, the client is very thin, de-coupled from view, and allows switching transports (default to http, and add web sockets when needed), also integration with some auth provider (like auth0) would be perfect as a plug-in

The reason why I find those use cases interesting is because it can run on Meteor apps, but also any SPA and static sites. While NextJS, Remix, Qwick, Astro etc., all want apps to run on the edge and server render components. I think there is something to be said about the simplicity of static sites (with some data fetching) and a SPA hosted on CDN. Not everyone needs server-side rendering and running on the edge. So a framework that can hook up to the backend, give some structure to fetching, make events pub/sub easier, and assist in auth while being thin and de-coupled could add a lot of value via simplicity and developer ergonomics. Adding that to Meteor with one click deploy and simple methods, and you have a nice, easy and well-architectured way to create many different apps.

[leonardoventurini]

Sir, you put into words what I have been aiming at all along, we will be in a very good position to do this as soon as I finish the split.