Sharing Meteor Methods between apps

[mvolkmann]

Is it possible to develop a library of Meteor methods that are used by multiple apps? Up to this point my Meteor Methods are used exclusively by the app that defines them. I can easily implement REST services that are used by multiple apps, so I’m wondering if the same can be done with Meteor methods.

[lucfranken]

Why not? Put them in a package and import them in multiple projects. For this scenario I think a meteor package would be suitable. If the code is more generic an NPM package is also an option.

[mvolkmann]

I was referring more to hosting of the Methods. Can I start a Meteor server and have multiple Meteor clients send requests to it? I suppose this would require the client to maintain more than one WebSocket connection … one to the server for the app and one for each additional Meteor server to which it communicates. Is this supported?

[peterfkruger]

DDP.connect(url) does exactly that.

Connect to the server of a different Meteor application to subscribe to its document sets and invoke its remote methods.

ARGUMENTS

url String
The URL of another Meteor application.

To call methods on another Meteor application or subscribe to its data sets, call DDP.connect with the URL of the application. DDP.connect returns an object which provides: …

[mvolkmann]

Thanks! I didn’t know about that option.

[drollins]

I’ve not played with this but I assume the user is whomever last logged in on the client invoking these methods correct?

[mvolkmann]

That is what I assumed.

[peterfkruger]

I knew about DDP.connect() but I never had any use for it, so all I know about this is from the documentation, and the rest is purely speculative. If someone’s around who has profound knowledge of this, please kindly step forward and shed some light on this issue.

My presumption is that the client logged in via the built-in DDP connection on server #1 will not be automatically logged in on the second etc. server(s).

Depending on what’s on that second server it may not even be possible: being a totally separate server it may even be connected to a different MongoDB where the user collection differs from those connected by the app server. Also, even if the second server connects to the same MongoDB as the first one, the server’s IP may be associated with a different domain name, resulting in different loginTokens (at least as far as oauth is concerned).

I also have a very uneasy feeling about this thing, since the app will keep accessing the browser’s localStorage associated with the origin domain (of the default DDP connection); meanwhile,if the second server’s domain is different, this is prone to wreak havoc.

I’m not even sure what a second DDP connection is really good for.

I’ve heard about the use case where this is supposed to be a way to avoid blocking the worker thread if a Meteor method on the server is heavy on the CPU, but to me it seems like a somewhat misguided idea. I tend to think that CPU intensive operations should rather be offloaded to a scalable platform such as AWS Lambda or possibly Google Cloud Functions.