Serving UI (react components) from another meteor app

help
1

I am still learning Meteor and my first project I want to tackle are microservices (as in multiple meteor apps) communicating with each other. I want to adopt the following approach:

  1. A client in the Frontend-App submits a request
  2. Request is processed by different microservices as needed
  3. Finally the resulting data is sent to the “UI Microservice App” which is basically a directory of React components which are injected with the resulting data.
  4. Finally that UI Microservice should provide the appropriate React-Component to render to the Frontend App which would complete the Request/Response circle.

Now I struggle with #4 conceptual-wise. I use meteorhacks/cluster to connect all apps via DDP. This works for handling a client request on another meteor app. But then what?
How would I send the react component from the UI Microservice to the Frontend App? Is there an obvious way? Does the FrontApp simply need to subscribe to the UI Microservice until something to render is available? Can I send React components through subscriptions?

Thanks for your thoughts.

Best
-act

2

This doesn’t quite answer your question, but I’m wondering if this approach will make things more complex than they need to be? What is the intent of your microservices? Could you not just have one main application that serves as the entry point to your system, that renders and controls the full UI? You could then have this main application communicate with your microservices, as needed. This way you could keep your router and UI components bundled together (since they’re so closely related), and you don’t have to worry about trying to find a way to pass your UI components from one application to another. You could then scale your main app up/out as needed (by load balancing it with meteorhacks:cluster for example). You could then also scale your various microservices separately from your core application. I think following this type of approach would make things easier to develop and maintain, but I might be missing something with regards to your requirements.

1 Like
3

Hi there - thank you for the reply! In fact I was thinking about the exact thing the last 30 minutes or so.

I came to the original idea by looking at companies like Netflix or Spotify where I got the impression they use a layer of microservices to generate/optimize UI data before sending it to a client. But the more I think about it, the more I believe that your argument makes total sense and that mimicking their approach (if this is even is their approach) would make everything overly complex.

So, yes, I can create different frontends (think desktop vs mobile) with different react components that serve as appropriate client entry points to communicate with the underlying microservices.

Thanks again, this was helpful.
-act

4

Is there a typo there or you really meant “send the react component”?

Reading your later comment: [quote=“actraiser, post:3, topic:26857”]
I came to the original idea by looking at companies like Netflix or Spotify where I got the impression they use a layer of microservices to generate/optimize UI data before sending it to a client.
[/quote]
… maybe you meant “send the react component data”?

If it’s meant to be “data”, then it’s an architecture worth considering for scalability (of users as well as development team). I think your idea of “UI Microservice” is similar to an API Gateway or a more specific Backend For Frontend (BFF).

With meteor specifically, the default pattern is to have a common codebase for B (Backend) and F (Frontend) as much as possible, aka isomorphic app. If you divide the B into appropriate microservices, and leave only the frontend-specific publications and methods in the isomorphic app, then its B part would resemble a BFF. If you want a strict separation of the BFF and F, the way you described in the original question, then you could use a decoupled meteor client like Asteroid.

5

Yes, you are correct. I actually started to look into Apollo Stack the other day and while it is still in early preview it seems to match my requirements plus ads GraphQL to the mix, which I find intriguing.

-act