share common resources between teams

[SassNinja]

The website says 'share common resources between teams' but I wasn't able to find detailed information about this topic.

If two teams use the same technology (let's say React) how can they prevent the client from loading a huge amount of assets (in particular the whole react vendor)?

I like the idea of verticalization and that each team is completely independent (own backend, own database, own frontend) but when it comes to frontend I'm afraid the client has to lead much much more compared to a frontend service that gets used by all (backend) verticals. I don't wanna lose features such as webpack's code splitting.

Are there any best practises?

[oleg-andreyev]

@SassNinja great question! Currently we are also researching "micro frontends" and we've raised similar question internally. One solution what we will try is to mark React as external dependency in Production and require dependency in Development, so the idea is to use React "interfaces" / "contracts".

[dennisreimann]

One solution what we will try is to mark React as external dependency in Production and require dependency in Development, so the idea is to use React "interfaces" / "contracts".

As long as you know what you are doing and are aware of the trade-offs, that is a valid approach to achieve this. Trade-offs here are that teams aren't really independent anymore and loose the ability to upgrade without coordination (i.e. synchronuous deployment).

Citing the website:

Don’t share a runtime, even if all teams use the same framework

This also has it's trade-ofss, as @SassNinja layed out this comes with performance costs, as bundle content will most likely contain duplication. Nevertheless, these trade-offs are considered and weigh less than the benefit of having independent teams that can ship and deploy whatever/whenever they want.

There is no one size fits all solution and assembling all of these parts can happen on a spectrum of choices. That's why it's more important to know the pros and cons of each approach, than to cast in stone the one valid micro-frontends approach.

[naltatis]

There is no one size fits all solution and assembling all of these parts can happen on a spectrum of choices.

Thats definitely the case. We've used different approaches. My current favourite one is to choose a tech-stack where the vendor library overhead is so small that it becomes a non-issue. Hyperapp, Svelte, Preact or Stencil are good candidates (I've talked about this here). In this case you don't need any inter-team contracts at all and the frontends can be self-contained.

If you need/want to go with a "heavier" solution you can serve specific vendor assets from a central place. But always implement it in a way that teams can upgrade independently so you aren't forced to to synchronouse deployments as @dennisreimann said earlier. When all teams reference e.g. the latest react the associated vendor bundle is only loaded once. When a new version comes out teams can upgrade on their own speed. For this upgrade period the old and the new bundles are downloaded. Implementing this requires the vendor bundle to be scoped/namespaced. We've implemented this using Webpacks DDL feature. Publicly served the DLL artefacts and distributed the associated manifest files via an NPM package to the teams. But this requires all teams to use Webpack, which might be an ok compromise.

A nicer and more standards compliant approach is using import-maps. Currently they are not implemented in all browsers, but they will. @trygve-lie wrote a good summary on how to use them in a micro frontends context. The single-spa FAQ also recommends the import-maps way.