"UI Services" for Single Page Application Dashboard?

1

Situation

  • I have an enterprise application dashboard (it’s hosted on the client site and retrievable at a subdomain: “dashboard.company.com”)
  • The user can purchase applications to add to the dashboard with the number of applications growing.
  • All the applications are accessed within the same subdomain (“dashboard.company.com/app1, /app2”)
  • Each application has it’s own meteor app “microservice” that provides the necessary data, subscription, methods, etc.
  • However, there is currently one “UI service” that serves up the dashboard interface (including the application UI for ALL applications). Which doesn’t seem like a party that can last forever…

Question
What are the options for separating the UI into their respective microservices AND still maintaining a continuous, “single-page” user experience? (So that the user can log on once and seamlessly move between apps while staying in the same window.)

one solution: iframes
The situation is analogous to just tying together multiple meteor apps. And the only way I know of for doing this is to use iframes and pass messages back and forth with postMessage so that the dashboard url is updated and linkability is maintained.
It seems like doing this is going to be painful, and the user is going to end up suffering a load time every time the application is switched…

  1. Are there any other options for dealing with this?
  2. When it comes to the iframe situation, what issues are going to come up beyond getting the url state to behave correctly? (the dashboard is accessed on mobile devices as well.)
1 Like
2

iFrames don’t seem the way to go unless you want to embed within an external page.

How do you now arrange authentication to the app1 and app2 microservices? Do they share the database and the cookies? Or are the requests really authenticated?

3

Re: current authentication approach

Assuming App1 is the “default”/primary app serving the UI:

  1. Login normally on App1 using the Meteor authentication package
  2. Pass the loginToken from localstorage via a meteor method to App2 Server
  3. App 2 server then (also via a meteor method) requests the userId associated with the hashed version of the token from App1 server
  4. Once App2 haas the userId, this.setUserId is called so that the user is authenticated on App2 for methods and subscriptions

Thanks a lot for the response. Let me know if you have any alternative ideas.

4

(The Dashboard uses React. Don’t think I mentioned that in the original post.)

It seems React’s component structure would be perfect for some sort of component API that could solve the “giant single page app” problem.

I’m thinking it boils down to this question:
“If I have a react component on a meteor server that does not serve the primary/default UI, how do I dynamically attach that component to a page and remove it when it’s no longer needed?”

There’s lots of ways to do this (it’s just adding js to a page I suppose), just need to figure out a way to do it with sleek Meteor style…

5

Alright, think I got my solution (webpack), but I’ll write up my findings once I’ve got it more completely lined out, still some more learning to do.

6

React does indeed seem to be a great solution with it’s components so that’s a good one yes.

Keep it quite native until Meteor comes with a real full solution for this kind of things. That keeps you flexible to adopt what you like on the newer Meteor-React integrations.

I was thinking about the authentication, do you share the database? Seems so since they have access too the user database all? If that’s the case: Why did you separate into multiple apps? With microservices I would more expect separated databases that’s why asking.