Distributed Meteor apps, with shared Meteor server, and GraphQL store

help
1

I have one large existing Meteor application, but I think it should be two.

There is an admin side and a “end user” side. The admin side can impersonate the “end user” (login as that user) and print PDFs from the file system. The “end user” side can only log in as themselves and print PDFs from the file system (the same files as the admin) and fill out Blaze forms.

Before converting anything over to Vue or React (haven’t decided yet), I’d like to break them out into two different applications, yet they should both be able to “see” the same file system, use the same server code, use the same database, and the “admin user” logged into the admin app should be able to “impersonate” a “end user” (log in as any user) on the “end user” app.

I’ll need some Account system similar to what I have today with Meteor Accounts – they should share the same MongoDB for Accounts.

Again, I need the solution to this app splitting to be compatible with Blaze to start, yet eventually will migrate the UI over to Vue or React.

Also, I need the ability to host all these apps/services on the same file system to start (EC2 instance, behind a ngix). Later, I can expand to multiple servers as I need to scale.

I tried out Asteroid for splitting up the app, it works, but the experience seems to fall flat when trying to retrieve subscription data from the “Server (Only) App”. The data is not in the form I’m use to with Mini-mongo, and I’m not sure how to make proper use of it within a Blaze style UI framework (most examples use Asteroid with React/Redux).

I’m now looking at Apollo/GraphQL education topics and strategies. The following is a diagram of how I’d like to set this distributed system up I think. Is it possible and a good idea to distribute an application up in this fashion? Does GraphQL play nicely in these situations (I know I’ll be giving up reactivity for now)? Are there examples of this Apollo setup laying around for me to examine?

Any advice you can give is appreciated.

Something I’d like to try:

452×538 25.2 KB

Another setup I have “working” (with the exception of cross app logins). Using Blaze at least, the subscriptions only return an object that cannot be queried in the same way as mini-mongo.

437×535 25.8 KB

2

I wrote up my experience here. So far, it has worked very well and I am able to subscribe to all publications on my back end server (server A) and use them on either client without issue.

On your 2nd diagram a couple of points:

  • How do you connect 2 different apps to one Back end meteor server? I was only able to figure out how to create 1 app, to get 2 different experiences I can have the code choose a path on load. And now with v1.5 this can be relatively efficient.
  • Don’t all account calls interact with the meteor server which interacts with Mongo? You show the clients directly manipulating Mongo. Do you mean mini-mongo on the client side?
1 Like
3

Using Asteroid. It’s a hybrid approach, where I can use the individual “client” meteor apps’ built in Meteor servers (like I do with Meteor Accounts) AND/OR the one centralized one. But I in this setup, I do use the Accounts package – so they both talk to the same user collection. The shared server handles meteor calls that would be duplicated across the apps otherwise.

4

I think to call another graphql server there are two ways.

  1. Using HTTP requests
  2. Using graphql function provided by the graphql library.

graphql function is not documented nicely so you really need to look at codes using this function.

1 Like
5

for the accounts aspect, maybe liberate your user accounts with Auth0. then you can take them with you (if you leave meteor)

1 Like