Redundant code sent down the pipe with Micro-frontends

Question

My understanding of Micro-frontends is that the key problem they solve is in helping enterprises have multiple, possible disparate teams, work on individual components/small-apps that will be used to compose a large web application.

Here the key problem being solved is the ability of multiple teams to work independently and still be able to build a large composite. The problem is NOT about having a lean release bundle for the end-user. Is that understanding correct?

Is it true that if we have multiple small-apps being used to compose a large web application, we could potentially have multiple small-apps shipping the same Javascript library (such as Lodash) down to the end-users' browsers as part of their individual vendor bundles leading to some amount of duplicate/redundant code being sent down to the user?

Isn't this a concern we should worry about while architecting the front-end application?

Answer 1

You're absolutely correct that there's a tradeoff involved here: you are trading in some aspects of the user experience to get a better developer experience (which in turn might improve the user experience in different ways). Is this worth it? It depends.

E.g. I think Spotify uses this approach to split their UI into isolated components (source). Each widget lives in an iframe and therefore can have its own set of libraries etc. They have the unique organizational constraint that work is performed by autonomous squads (a cross-functional team). This makes it more difficult to agree on company-wide standards and later changing these standards. So for them, micro-frontends help preserve some flexibility. But without this approach, maybe their desktop app would be less of a memory hog.

HTTP caching is not going to help much: each micro-frontend might use different framework versions. Additionally, the cost of duplication is not just the data transfer, but the client-side costs of (re-)compiling the libraries and storing duplicated data structures.

Personally, I think such micro-frontends can be a valid architecture but are probably inadvisable unless

• you are a very large organization with highly autonomous teams that all work on the user interface and need to do very frequent releases (e.g. daily) and
• your UX performance budget has room for this duplication, or your product is so good that UX doesn't matter. Note that performance should be tested on low-end devices, not on your development machine.

If your organization is not huge or if your teams are a bit more specialized, it might be easier for everyone involved (management, developers, and ultimately users) to have a common build and deployment process that avoids unnecessary duplication. E.g. if you only have 4 teams working on UI they can probably talk with each other to agree on a common set of libraries, and how to integrate their work into a cohesive architecture.

Micro-frontends seem to be one of these things that are really cool but that you don't quite need until you operate at a scale.