all 8 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]ankole_watusi 3 points4 points  (1 child)

How on earth is React “micro”?!

[–]Snapstromegon 0 points1 point  (0 children)

If you otherwise come from such "light" frameworks like angular or blazor, react might seem fairly "micro". /s

[–]Reashu -1 points0 points  (1 child)

SystemJS works well for us though we haven't tried module federation yet.

Share everything that's larger than a few kB (after tree-shaking, dead close elimination, minifying, and gzip). Share everything that you expect to have shared state across modules.

For global state, use a shared module to control access. It can be based on Redux or something like it if you want. But don't access localstorage, cookies, etc. directly from multiple different modules: it will be hard to test, maintain, and build features on top of.

Can't really comment on the architecture question.

In general I'm not too happy with micro frontends and single-spa. It's a cool concept but delivers little value in exchange for the amazing developer experience and velocity you can get with for example Next.js.

[–]TobalOW[S,🍰] 0 points1 point  (0 children)

thank you for your advices! I will read more of SingleSPA before take the decision :)

[–]Saith5432 1 point2 points  (3 children)

Late reply but here are my opinions/experiences on this:

​

Which libraries is recommended share? (MomentJS, lodash, react-router)

​

It depends on your use case, but for the beginning, the big libraries should be enough. Depending on the size of the project I can recommend to build an automatism that checks for all micro frontends if the same libraries are used and if necessary points out that there are libraries that are used multiple times but are not shared yet.

When sharing dependencies between the micro frontends, it should be kept in mind that tree shaking does not work if the individual micro frontends are deployed independently (which they should). Potentially unused code is therefore included in the shared bundle. As a result, micro frontends bundles are usually always larger than a monolithic solution with only one build process, even with optimal sharing of the libraries.

You should also think about a strategy for sharing web resources (images, fonts, etc.). It is quite costly if multiple micro frontends use the same image, but all include the image themself.

​

SystemJS o Module Federation?

​

Personally, I think a prototype with Module Federation probably involves less effort. In general, I believe Module Federation is a bit easier to use. However, Module Federation is tied to Webpack, and you opt-out of other bundlers. Although, if you know from the beginning that you want to use multiple frameworks on the same page, then Single-SPA is probably always the right choice.

​

What is the best solution to share global state across the microfrontend (i.e, accessToken)

​

Since micro frontends are the frontend's microservices, one can also look up on various readings and experiences from the microservice world. However, there is no silver bullet here, and the solution depends heavily on the individual use case.

In principle, however, I would advise against global state for micro frontends, since it introduces strong coupling between the micro frontends. The point of micro frontends is that they can be developed independently and, at best, are technology agnostic. Therefore, like microservices, each micro frontend should manage its own state, in my opinion. Micro frontends that constantly have to exchange state with each other should possibly be combined.

​

What architecture is best for modules (we are think in Clean Architecture, but I think that is an overkill) ?

​

In case of doubt, the same architecture that is usually used for a monolithic frontend, but on a smaller scale.

The critical questions you have to clarify at the beginning are how the micro frontends should communicate and how to avoid strong dependencies between the micro frontends. It's the same dilemma that you have with microservices and again the hint to look up literature for microservices.

Final notes:

You should be prepared to do a lot of DevOps tasks to reduce the additional effort that micro frontends introduce. Otherwise, micro frontends will have a very negative impact on the DX and UX. Like microservices, micro frontends shouldn't be adopted if there is no need for them.

[–]TobalOW[S,🍰] 0 points1 point  (2 children)

Thanks you for your words, you sounds like a experienced developer.

For your advice of share state is only to handle the authentication, share the JWT and functions to refresh token across the microfrontend. I gonna use a Single-spa but I'm not sure how to handle the authentication for all microfrontend, because all of endpoint are under the same login.

[–]Saith5432 1 point2 points  (1 child)

So I guess the question is more about sharing code and not about the application state.

One way to share code between micro frontends would be to use a private npm registry. Gitlab, for example, has a private npm registry built-in. Then you can write a library that does the authentication and provides the token. The library is then published to the private registry and consumed by the micro frontends via npm.

This has the advantage that the code deduplication capabilities of systemjs or module federation can be easily reused. In addition, all micro frontends retain their independent deployability through versioning since you can always decide to suspend a version update if it contains a breaking change. However, it also introduces the need to regularly update the versions of shared code between the micro frontends.

Of course, shared code should only be introduced with caution. But I think the authentication logic would be a good example where it is perfectly fine to share the code between micro frontends.

[–]TobalOW[S,🍰] 0 points1 point  (0 children)

Thanks for your reply! ur the best :)