We’re currently using subscriptions on Meteor to get our app data and have optimistic UI updates in methods.
However, we plan to make our server ‘stateless’.
This means replacing all subscriptions with methods to fetch the data. We would still use minimongo in the browser to have optimistic UI in method calls. We might use polling to regularly sync with the server.
Since DDP is inherently stateful we likely have to write a custom REST wrapper to call our methods without Websockets.
Does anyone already have experience with this?
If we succeed in building this, we might release a community package for this purpose.
It’d be great! It’s easy to switch from reactive publications to methods with grapher, but it’d be better if there were a way to populate a local collection with the data coming from methods with some helper functions like refetch, update-after-mutation, etc.
Meteor’s DDP is inherently stateful as it maintains an active session on a single server for a user, both for auth and for pub/sub’s mergebox. If you only need unauthenticated methods then it can be stateless, but I imagine most ppl are authenticating users via one of the built-in accounts packages.
Is that not the same as a persistent HTTP session? You can use it without auth, and so long as the methods you’re calling complete, then on disconnect/reconnect (even to a different server) nothing will re-run
It’s not the same as a persistent HTTP session. It’s stateful because a single server out of your cluster is maintaining an in-memory session for each particular user, the fact that it’s over websocket or HTTP isn’t actually relevant. That’s why you need sticky sessions enabled when you deploy.
Meteor is built from the ground up with these stateful sessions in mind. You certainly could get around it but you wouldn’t be using it in any standard way.
The in-memory session only tracks pub/sub and user data (as far as I know) If you submit your user authentication as arguments to your methods (and exclusively use methods), would this not make it stateless?
Yeah you could, that’s what I was getting at when I said that it is possible, you just wouldn’t be using Meteor as it was intended. You’d still have to load balance your sticky sessions tho, as each client would still need a persistent websocket connection to a single server to make their RPC method calls. That is unless you replaced all websocket methods with HTTP requests. At that point tho, you may be better off just using another framework.
Got it - I was thinking about services like AWS Lambda, where you can have a server for 15 minutes, but then lose it. So a user who connects for < 15 mins would always be on the same server, but for longer, would disconnect and reconnect to a different server. Because of how lambda works, it could even be connected to the same “server” after the 15 mins, but a new session
In general I believe lambdas are best for one off actions in response to other actions. Moving a REST API entirely to lambda often isn’t the right move (example).
Spinning up a Meteor server is slow and it eats up a fairly significant amount of memory at idle, so I suspect it might be pretty expensive and inefficient to put a Meteor app behind a lamda, but if anyone’s done it I’d love to hear about their experience.
We deploy using AWS Fargate which is a managed service based on Docker images, and I’ve been happy with that solution so far for a stateful Meteor app.
All of this could change tho once Apollo is treated more as a first class citizen in Meteor, which Ben and the team have hinted at recently. So maybe in Meteor 1.9 or 2.0 we could get closer to an easy stateless solution
Interesting - yeah we don’t use lambda for this, and I’ve had similar concerns (one server per connection, even on lambda is massively wasteful). Thanks for the link too, it’s certainly food for thought. We use lambda for very specific functions right now, e.g., video transcoding of short clips, where the server spinup time is longer than the transcode time, and it works great for that
