Please share your experience and thoughts. Do you implement host functionality, microfrontend functionality? Which frameworks(s) is used - blaze, react, vue? What about webpack moduleFederation? Is it possible to use blaze components(templates) in one meteor app loading them from another running meter app in runtime? Any approaches are interesting!
I do have experience with microfrontends and Meteor. Microfrontends should really be used as a last resort, because there is no way to efficiently share state and dependencies. If you do need a split, I would recommend to do that horizontally. This means building a design system in your framework of choice (react,vue,svelte, etc). Important part is to leave out the smart part (see Meteor guide on smart components:). Thatās up to the framework and your state tools.
Anyway at a number of clients Iāve seen setups where essentially each micro frontend became an application with its own API, Serverside and clientside. Meteor would be perfect for that scenario. This is assuming you split your frontend based on pages. Of course you would still need a design system to share components and design implementation.
Each framework has its own caveats when it comes to dealing with this scenario. Meteorās limit would be on the accounts side. You will need to figure out how to share sessions. The other limit would be the realtime layer. Meteor works best as 1 app.
At time of writing there are a few attempts on creating micro frontend frameworks. There are not really good solutions yet in my opinion. I would really recommend to use it as a last resort. Most of the time people do it because their teams grow. If thatās the case its better to take my horizontal approach:
- Design system team
- State team
- API team
etc. Anyway. Can you be a bit more specific about your use-case? I can tailor my answer a bit more or at least point you in a good direction.
Thanks for the answer.
In our case, we are trying to find a way to scale the development of the project and donāt run aground. At first glance, microfront ends have their advantages - development teams are independent of each other, except for design, and we can delegate to develop features to different teams. Each team has own repository.
Pros: no tight coupling in dev environment, each dev team has own repository an probably can use different frontend framework (React, Vue, Blaze). Itās, may be, more secure, the dev teams donāt have access to all code base, although this argument may seem far-fetched.
Cons: the technical complexity.
Yes, Meteorās account system is the challenge, but we plan to move all data from MongoDB to our API, including user accounts. The API provides data to others our applications like mobile apps. Meteor backend turns into caching proxy with reactivity features in this case.
Another way: to glue different parts of the application in the build phase via using npm packages for example.
We use the classic way: one git repostiory, branches, merging and so on.
Iāve tried micro frontends with a lot of different frameworks and have first hand experience from other people working in large companies. Whether you use Meteor or any other tool like Next, Nuxt, Gridsome, etc. You will run into exactly the same issues. In theorie micro frontends are nice, but in practice itās very complex and youāll often create more issues than you would have when working on 1 project.
Iāve been wanting to dedicate one of my entire livestreams to this topic. (not yet online) How to scale frontends into independently working teams that benefit from each others work and at the same time are independent from each other.
The default I see happening (because some very large corporations decided to do it) is that the split happens on page level. Each ārootā page (one segment of the uri eg: /articles, /products, but not /articles/:id) would be one micro frontend dedicated to a specific domain.
In theory this should work, but in practice features are shared between pages. For example a heading or even the entire article. Then one of the teams decides to have a variant of the article, making it the ProductArticle. Hereās the problem. Which team is owning this component? And what parts? So besides the technical aspect there is a solid case to not do it this way.
You could however go for ultimate composability. So 1 team owns the Product component, but makes it very composable. The other owns the Article component and makes it very composable. Then both teams could share each otherās components as a service. In practice however, you will end up with a big bowl of mud that magically becomes the design system. No clear overview of which components are where. You could create a package for that. This then becomes the ādumping groundā of shared components from which no one really knows how they are used and if they are even reused at all. This is simply because there is no ācore teamā that maintains and decides the direction of this package. (so you would need a team regardless so why not have that team build the design system)
On state level things become even more tricky. Lets keep it simple. We all use React in this example. Team A decides to go for React with Redux. Team B chooses to use just the React Context. Team C goes for Recoil. Now each team will have to makes an implementation of the same feature with their own library which will lead to many inconsistencies especially when one team delivers and the other still has to build it.
On the clientside things are not nice either. The browser will now have to load multiple bundles with different dependencies, making it impossible to cache things. Customers also donāt follow your micro frontend rules. They have journies. In a webshop for example, customers jump from their basket to the product search page and might occasionally end up on some information page to read up about specific promotions. In other words they have a customer journey that would happen between micro frontend. Since you canāt simply React Route your way to each frontend, you will not only loose app state when people navigate back and forward. You will also require them to reload your entire page. This really is a showstopper imho and completely undermines the added UX of modern frontend frameworks.
I know that Iām making a long statement here, but itās much better to make the split horizontally. Ensure that there is an API team, a design (dev) team and a project team. The API team could later be split into teams that manage specific endpoints or a specific business domain. For example the order service and the product service. Make sure that these splits really occur on the lines of business domains. On the frontend part you would have 1 project team. They can be seen as the composers. They donāt make the actual design implementations, because that would be the design system team. The project team focuses on customer journeys and collaborates closely with the design system team and API team. The main goal here is to keep the footprint of the project team as small as possible. Itās better to have a lot of supporting teams that act as services than to have 1 big project with multiple teams working on it.
Just like the API team, you can split the design team and project teams too. One part of developers would focus on a specific set of components, but they are all combined into for example 1 storybook and are built via 1 styleguide and 1 framework (React, Vue, etc). The project teams could be split per customer journey. (order flow, registration flow, organic search flow, etc).
A major advantage of having this horizontal split is that you can now really leverage the developerās skillset. Frontend is large. A frontend has to know about API, design, state management, build tools etc. Horizontally splitting helps devs to focus on what they are best / most interested in and this generates some real value for the company.
Iāve explained the above for a reason. If you split it like this, you will end up having options to migrate to new frameworks without requiring other teams to switch too (or at least right away). You could build for example a new design system in Vue and out-phase React. Meteor (also webpack) is capable of supporting both.
Hope I gave some valuable input. For me also a good practice to articulate my thoughts on this topic. I will definitely write more on this. Good luck anyway ! 
2 Likes
Thank you so much. Your feedback is very valuable. Moreover, I have similar concerns about microfrontends.
1 Like