Meteor, microservices, data flows and authentication

There is a website, which generates analytics events.

There is also a Meteor-based Analytics App. It has a REST API to record events and is connected to an Atlas DB.

Finally, there is another Meteor-based App, “Actual App”, which consumes this analytics data, but uses an in-house MongoDB cluster as it’s primary data source.

The analytics data is separated for performance reasons, since it’s expected to create a lot of writes.

There’s at least three ways to get that data to the Actual App User:

a) :red_circle: Connect the Actual App directly to the Atlas DB and use the Analytics Event -collection like any other.
b) :green_circle: Fetch Analytics data for the Actual App client directly from the Analytics App
c) :orange_circle: Have the Actual App fetch the data from Analytics App and then publish for the App User

Solution a) seems easiest, as authentication is already baked in. Some configuration complexity from connecting to another database. Solution b) requires implementing an authentication mechanism (SSO) so the App User can only fetch their own data. Possibly the Analytics App has to become aware of user documents. Solution c) can rely on a shared secret between Actual App and Analytics App, where the Actual App handles the authentication and logic for determining document access rights.

How would you implement this? :thinking:

I’ll do C, so that there is a separation of scope and minimize complexity.

  • each server has access to a single DB
  • each app-client has access to a single server
2 Likes

d) Client of Actual App fetches the Analytics from the Analytics server via REST or from the Analytics App via an Iframe. It is like the slingshot concept, skip as many servers (or links) as possible to achieve the same result.

1 Like

This would require sharing the user documents between the two Meteor apps, and the login token via Iframes somehow, correct?

I use a cookies from an old package which was possibly named ‘persistent login.’ This cookie is visible at domain level and I can read it from the browser inside any iframe that loads that a subdomain of that domain.
Let’s say I have App and Chat. App is the ‘master’ app and I load the chat in it in an iframe.
My App is hosted at app.com and the chat is chat.app.com

I load an Iframe with https://chat.app.com/?u=${Meteor.userId()}.

Within the Iframe, in Chat, I read the cookie and also get the userId from the Iframe url.
The cookie is not the plain login token…
Before I set the cookie in App, I call a method (server side only method) which takes the login token from browser’s local storage (but this can be taken directly server side from the user) and encrypts is with a passphrase. Then, sets this as cookie.

Chat, reads the cookie and does the reverse, calls a method to decrypt the cookie (on the server), gets the token and logs in with it. I know from the URL who I might be as a userId. If the userId matches the decrypted login token, ok, it is me for sure.

I talk between the App and Chat via a listeners API and call logout on the Chat when the App logs out. However the logout also removes the cookie and the local storage. If these are missing, Chat is logged out.

I use assets cacheing via service workers, persistent data storage with IndexedDB and bundle delivery via CDN and the whole thing seems to work together as one.
I am planning to add some business tools and an e-commerce on top of everything.