Stateless Meteor server with methods

timoho · 2019-09-20T12:15:31.488Z

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.

znewsham · 2019-09-20T12:36:45.055Z

Why is DDP inherently statefull? Beyond having a persistent connection. You might look at this package:

github.com

stubailo/meteor-rest/blob/master/packages/rest-method-mixin/README.md

# simple:rest-method-mixin

A mixin for [`mdg:validated-method`](https://atmospherejs.com/mdg/validated-method) to configure the HTTP endpoint for that Method when using [`simple:rest`](https://github.com/stubailo/meteor-rest/blob/master/packages/rest/README.md).

Use it like this:

```js
const method = new ValidatedMethod({
  name: 'method',
  mixins: [RestMethodMixin],
  validate: ...,
  restOptions: {
    url: '/my-custom-url',
    // any other options
  },
  run() {
    return 5;
  }
});
```

This file has been truncated. show original

csiszi · 2019-09-21T07:06:51.983Z

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.

efrancis · 2019-09-23T19:17:45.075Z

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.

znewsham · 2019-09-23T19:35:49.862Z

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

efrancis · 2019-09-23T20:46:21.044Z

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.

znewsham · 2019-09-23T21:04:21.582Z

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?

(not trying to cause problems, genuinely asking)

efrancis · 2019-09-23T21:18:16.250Z

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.

znewsham · 2019-09-23T21:20:48.139Z

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

efrancis · 2019-09-23T21:28:16.966Z

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

znewsham · 2019-09-23T21:33:09.386Z

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