Sorry for what might be a noob question. I just can’t get my head around how Meteor handles variables when concurrent users are on the backend (in my case through several API calls).
Is Meteor isolating an instance for every single new request that is coming in?
If so, how are global variables affected? I want to avoid that a new request is overwriting a global variable with it’s own value while another request is just about to use “his” global value.
Can someone point me either to a resource on the internet that is explaining how concurrent users/requests are handled by Meteor on the backend as I couldn’t find anything directly on it.
Only references I could find are about session and other reactive variables which seems to be only being used together with the frontend.
I think server global variables are exactly that - global. You might want to create some of those globals as a dictionary with the userId as a key. Another approach (what I would recommend) would be to store state in the user object itself.
Behind the scenes I think each request runs inside a fiber.
Hi @energistic (or Daniel), thanks for your response. I think putting the global variable that I’m worried about (which is cookie data) into a dictionary might become a problem with tens of thousands of possible users (not concurrent but over time). There must be some recommended way to do this, not sure if this is in the Meteor guide explained as well. @sashko is there a recommendation how global variables are being held exclusively when it comes to concurrent users (on the backend side)?
As for your second comment, yes, I store the cookie in the user document. So retrieving it when the users logs in is the first action. What I’m worried about is when he works with it. Currently it’s defined as a global variable as I’m tired of using it as a parameter for every function that I call and nest further into it.