Server-to-Server: Connection handling and Method calls

My setup
2 apps connecting to the same backend (most likely there will be more than just one common backend in the future).

For simplicity let’s just consider having the app (that’s the frontend implementation) and the backend.

Current status
Establishing a connection and calling methods on the backend basically works. But I discovered the following issues.

Issue: Setting up the connection
When or where should the connection be set up? “Methods from a given client run one at a time” (see docs). If we connect to the backend on startup, we will use the same connection for every method call. This means that you should call this.unblock() from within the backend method or otherwise it would dramatically slow down the whole app the more users are connected to it.
To work around this I’m thinking of setting up a connection per user some how. But I don’t know how. Or connect on each method call.

What would be best practice here? Or which implications does each approach have?

Issue: Calling a method
Let’s assume we handled the connection stuff. Now we call a method on the backend connection.

  1. How should the method be called? Sync or async?
  2. How (and maybe that’s the most important question) can we handle the case when we lost the connection to the backend? This might be a common scenario.

My current solution for 2) would be to check the connection status on each method call. If Meteor.status().connected is equals false then I just throw a new Meteor.Error so the client could just tell the user to retry.

For some operations we might go with eventual consistency by waiting for the connection to reconnect. But that’s not the default case.

I’m a bit confused. So let me try to recap. You have two front-end apps and one shared backen (ie. the server is the same for both of them and somehow you managed to get them to connect to it and serve the two different apps based on your rules).The connection is setup in the config, let’s skip how this would work for now.
From your title, though, I get the feeling that you have two apps, say one for creators and one for consumers. Both are independent Meteor apps and you need them to communicate. The easiest approach to that is for them to share database and the oplog will take you a long way.

What the docs are refering to with the client, is connection to one user. As the docs sais it will run only one method per client at a time. If you have a method that takes a lot of time or can run in background and you want the server to execute the next action from the user then you use this.unblock(), no need to use it everywhere. Others users run in their own thread (at least that is my understanding). So in essence your first issue is already resolved. (Unless I’m completely wrong on how this works.)

I think you might want to look into Apollo for your project as it seems to be designed more towards your problem. In general I would lean towards one app communicating with the backends (be it database or service) it needs to and have the other app pick on the changes.

Thanks for taking your time to get an understanding of the whole thing.

You’re right, there are two frontend apps and one shared backend.
Let me clarify it a bit. Here’s a chart which should show the whole thing.


First: I don’t want to integrate via MongoDB. I want to keep the business logic in one place (the backend). The app will grow quite big and I need to be as flexible as possible. Things like a chat could be separated into its own micro service.

Next thing: What you write about this.unblock() is exactly my understanding. That is true for the user connection from the client to the frontend server. Up to there everything is clear.

What I want or need is to find out how this whole thing works when the frontend server is the DDP client and connects itself to the backend. My current implementation is to open the connection on startup so I’m reusing the same connection for all method calls. So if two users call the same action the backend method is also called twice, but from the same client (the frontend server).

Hope that makes it clear now.

1 Like