Sticky sessions required?

apollo
1

Hey community,
I got a question related to sticky sessions, meteor & apollo.

We are using meteor together with apollo graphQL for our application. We are also using meteor accounts package with is using the DDP protocol internally. As far as I know meteor requires sticky sessions because of the DDP and to scale properly.

→ Is this still true if I use DDP only for the accounts package and what would happen if we disable sticky session? Especially in terms scaling to multiple app containers and serving a lot of clients.

If disabling sticky sessions is not a good option, is there a good way to use meteor accounts with apollo graphQL and get rid of DDP altogether?

Thanks a lot!

2

You can send login form data via mutation call then on the server, you call the meteor login method, send the result which has a token to client. Then everytime you call mutations or subscription, you can send with that token in the request header.

3

Hi minhna,

thanks for your reply. In this solution I can get rid of DDP altogether right? Do you have any minimal code example or documentation about this?

Do you have any thoughts about using DDP for the accounts package without sticky session?

4
  • I don’t know “sticky sessions” is the right term.
  • I don’t have any problem with the default Meteor setup
  • I don’t have problem with the DDP
  • You can use Apollo/GraphQL without using DDP
5

What I mean is, if you use DDP it’s recommended to use a sticky session cookie to route all requests from one client to the same server instance/container. This limits somehow the load balancing possibilities because already connected clients will be routed to the same server even under high load. If sticky sessions are disabled, every request from a client will be routed to a random server → better load balancing.

That is why I try to get rid of the sticky session requirement or if not possible with DDP, get rid of DDP at all…

6

On one of my website project, I’m using load balancing with sticky session on google cloud. I’m also using auto scaling feature, if the server group reach a level of load then it auto creates new server then new clients will be routed to the new server. It works well. I don’t need to drop DDP and switch to Apollo/GraphQL only.
On my other project, a React Native app, which uses Apollo/GraphQL only and it works well too.
I think you can give it a try first, sticky session load balancing is not bad.

7

Ok great, thank you!

In your Apollo/GraphQL only setup, do you use Meteor accounts package without DDP or do you have a different approach for accounts/login?

8

Yes, I use meteor accounts (server only).

9

But you need a signup or at least a login function from the client side, right?

10

Yes, I create a login form, when user submit it, I call a mutation with those data then on the server, I call the login method, then send back the token to the client. On the client side, you need to store token in a safe place (encrypted) and send it via the request header every time you make a request.

11

OK, perfect, now I am getting the full picture… I think fist I will stick to the Meteor client side accounts implementation (using DDP) but if we one day want to get rid of DDP altogether, that’s a good option!

Thanks again for your help!

3 Likes