Some time ago we organized the first "Micro Frontends Conference" - a free fully remote event for the micro frontends community. Pretty much all speakers could make it live to the event, which had a lot of questions asked via YouTube or the Discord community chat. However, one of the speakers was traveling on that day and fortunately decided to still participate by providing a pre-recording of his talk.

Being the great speaker and community member that he is, Manfred Steyer offered to answer the questions for his talk later on. In this article we want to share the answers to the questions asked during his talk.

Questions

So this sounds like another way of doing service discovery, right?

Manfred: Well, if the manifest.json is not just a static json but the result of an “REST” API then it can be used as a kind of service discovery. However, someone needs to implement the management part on the server side.

How would fallback-alternatives be defined for runtime module imports, say using a code split from source if the remote module hosting server is unresposive?

Manfred: You can just use a catch clause when lazy loading the Micro Frontend.

How would this work with React?

Manfred: It works the same way. You find some examples on the npm page. The current challenge with React is that it does not ship ESM bundles. Converting from CommonJS is possible, but there is not the one and only way that works all the time for this. This can be a bit challenging.

The current implementation was tested with React and we even included some solutions for converting to ESM. If you run into troubles, e.g. with some 3rd-party-vendor libs, please let me know.

What was the biggest challenge of building "native-federation"?

Manfred: Honestly, it was straight forward. I had a working POC in some hours, however, making it look like Module Federation took 2-3 additional weeks.

Apart from bundle size - any other reasons to share dependencies?

Manfred: You can also use shared libs to shared data. In this case, the lib acts as a mediator or a mini-service-bus.

Why are we making MFE's so complex, can we not have a standard/specification way of working by hiding all the Impl details and Frameworks/vendor agnostic?

Manfred: That would be great. Currently, nothing is in sight, unfortunately.

In your opinion is better to go lib agnostic or keep with the most supported tooling such as Piral or MFE?

Manfred: Piral works on a higher abstraction level. It’s a framework orchestrating SPAs. The Module Federation approach is more low-level, but it allows you to use your leading framework at the orchestration level. Both approaches have advantages and disadvantages.

I remember your previous talk (JS Kongress) which sponsored the micro frontends with the use of web components. Is the approach you propose today better than the previous one?

Manfred: Using Web Components allows you to abstract differences between frameworks and framework versions. Hence, you can mix and match multiple of them. However, they come with two drawbacks: a) you need some custom infrastructure code for loading them b) by default, each separately compiled web component bundle has all its dependencies.

Hence, if you have 5 bundles, you might get your framework 5 times. Native Federation/ Module Federation compensates for this. For a multi framework/ multi version scenario, you could use Web Components together with Module Federation/ Native Federation. In this case, the dependency is shared when its compatible; otherwise another version is loaded.

Do you see any challenges with native-federation in hybrid apps or webview?

Manfred: Hybrid Apps are not my focus but I have some customers who use module federation with hybrid apps and they told me it works well.

In order to import for future modules and implement an effective cache strategy, we can consider using either versioning /semantic or hashing?

Manfred: For caching yes. For the meta data used by Module Federation/ Native Federation we should go with semver.

Can the modules define "peer dependencies" for the host?

Manfred: Well, at runtime there is no difference between different kinds of dependencies. It’s just a ESM-based bundle loaded on demand.

How does the templates for loading different app fragments look like?

Manfred: Normally, the templates are compiled to EcmaScript. At least, this is the case with all current SPA frameworks. Hence, there is no need to share such templates separately.

Are templates controllable on a per-request basis? - when working on the shell -- how do we get IDE autocomplete for things that remotes expose?

Manfred: You could share an interface. But normally, the contract between different Micro Frontends should be really small.

In the best case, you integrate via the router so that you only need to activate the loaded component without assuming any properties or events. This works well, if you manage to split your application into decoupled vertical parts according to DDD/ Strategic Design.

Are declarations parsed at bundle time?

Manfred: At bundle time Native Federation creates an bundle per shared lib and exposed module found in the federation config.

So, goodbye iframes?

Manfred: Well, iframes still have their use cases. If you need a very good isolation or if you need to integrate traditional web apps (JSP, JSF, ASP.NET, PHP, …) they can be used. Even SAP uses iframes within their Luigi Framework.

Does native-federation want to replace module federation?

Manfred: For me it’s an insurance that the mental model of module federation will live on even if we move away from webpack. Angular, for instance, is slowly moving over to esbuild.

Why not make module federation embrace import maps instead of implementing another standard/lib?

Manfred: To make the mental model of Module Federation tooling agnostic, my take was to implement it mostly outside of the bundler. As a result, you can use with together with other bundlers like esbuild.

single-spa is heavily dependent on import maps. Have you ever compared pros. and cons. comparing their implementation with native-federation?

Manfred: Yes, they use them, and the most common approach to using import maps there is SystemJS. While Single-SPA is a meta-framework, using module federation/ native federation allows you to use your leading framework for orchestrating different micro frontends. No additional framework is needed.

Also, by providing an abstraction, you don’t need to deal with Import Maps by hand. Like Module Federation, Native Federation uses your config and takes care of everything else (putting shared libs in separate bundles, applying strategies for bypassing version conflicts).

How to handle shared dependencies across federated modules? for large projects

Manfred: If you have a monorepo, you can ensure that at a given time, just one version is in place.

If you have several repos, it’s about governance. However, here, you could always get different versions hence abstracting your Micro Frontends with Web Components could be a good idea here.

When does it make sense to use microfrontends?

Manfred: In general, if you have several teams that cannot work together in one monorepo. For me, this is the main reason. On a technical level, Micro Frontends also help with migrating from one tech stack to another one little by little.

Conclusion

Thanks to @manfredsteyer for his participation in this great event and also for answering the questions so swiftly. Much appreciated!

You can follow Manfred on Twitter or get in touch regarding Angular Workshops.