Controlling several Meteor app from a central Meteor app

Hello!

I would like to know if there is a best practice on how to control a large number of deployed apps from one central Meteor admin application. Typical tasks would include fetch statistics, creating items in collections and so on.

To make my question a bit clearer, here my situation. The app that I am developing at the moment should be deployed to a cloud, on instance for each client (institutions in my case). This should be done to make the apps run independently from each other, so only crashes and not all. As an admin, I would like to have a central admin application which does the tasks mentioned above to perform the tasks an admin has to perform without much difficulties.

I read about remote collections using DDP.connect which would mean that I have to connect to every single collection on every other app. Could exposing a RESTful API also be a possible solution? Are there any disadvantages of it? Any other suggestions?

Separate databases for each app?

I’m building https://trombone.io which uses a separate DDP connection per app, in my experience so far it’s been straightforward to get setup - subscribing to publications/call methods from remote apps is as easy as working with the current Meteor app.

For security you can setup an admin user on each client client app and login to the app over the same DDP connection.

Jap, separate databases for each apps

Ok, thank you a lot. I read about connecting to remote databases, but remote method calls are new for me. I will have a look. Did you experience any great patterns while working on trombone?

My solution is to create routes in the applications and call them from the admin app. Simplest to implement. Since Meteor can keep doing things even after it responds to a URL, I just set URLs for things I want the client app to do, URLs that are not public and that require some parameters to work correctly.

How do you secure those routes?

DDP.connect() is quite powerful for this

The object you get back provides most of the same properties that you typically use from the client with a Meteor app.

So if you have an adminStatistics collection (or any other collection) published on your client app to your admin user, from the admin app you can do things like:

var remoteApp = DDP.connect('https://app1.com'); remoteApp.call('login', adminCredentialsObject); RemoteAppStats = new Meteor.Collection('remoteAppStats', { connection: remoteApp } ); remoteApp.subscribe('adminStatistics'); remoteApp.call('someCustomMethod' , payload, options);

and you can even do this from within a template onCreated() function, and it’s fully reactive - any writes you do will go back through the standard allow/deny rules for that publication etc.

Thank you a lot for your helpful answer. Do you know any restrictions that come with this approach? (you said ‘most of the same’)

To secure those routes, you set up IP controls.

I also set up private (non-public) HTTP form parameters. Just to be on the safe side.

1 Like

There are two approaches in connecting to another Meteor application. Let’s call the app you want to connect recipient and the app that connects to the other app client.

One of them is the approach I employ: Creating routes in the recipient app and calling them from the client app. The recipient routes can be plain HTTP forms, JSON, or XML. Let’s call this API method.

The other approach is by DDPing to the recipient app. The one that @pauljohncleary uses. Let’s call this DDPing.

There are pros and cons to both approaches.

The API method is battle-tested, industry standard. You can change the underlying code without changing the API. The client does not need to know anything about the actual structure of the database. On the cons side, this approach is not reactive.

Unlike this method, DDPing to the recipient app, is reactive. If anything changes in the recipient app, the client app will see it automatically. But it has a few disadvantages. Both apps need to be Meteor, or setting up this method is painful. But the most important problem with this approach is that you need to know the recipient application’s database structure/publications inside out. Note this though, even if you know/own both applications, changing something in either app will mean changing something in the other app too. Not everything and every time of course; here is an example: Let’s say you decided to rename a field. You need to modify both apps. You decided to change login method. You need to modify both apps.

My two cents, you should go with the API approach.

1 Like

Good points- one big advantage to the DDP method is that it requires the least amount of effort to get going, you just subscribe as your app currently works and you have your data.

Although yes, you lose the advantages of decoupling your app and api, which is something IMO meteor as a whole is (intentionally?) poor at.

In terms of what you get with ddp.connect vs normal meteor, you don’t miss out on anything that I can think of…

Ok, I really see the advantages of going with the API approach. The arguments of @necmettin make sense, especially because I am more or less at the start of my developing process, which means the underlying database structure may change a lot.

Which of the api-building-packages do you recommend? I have read about Restivus, can you recommend it? Did you experience any issues when trying to implement the control mechanisms with one or another package?

Yes, Restivus is what I would recommend. It’s the most flexible one I know of. There are a few more alternatives but I would go with Restivus. simple-rest is (I think) official but it’s not as easy to implement as Restivus.

http://www.meteorpedia.com/read/REST_API is not that fresh but I advise you to read it.

1 Like