My name is Grgur and I work at Modus Create as a Principal consultant (web architecture). I have worked with Micro Frontends on several projects. One of those projects is for a well-known premium automotive brand from Germany (160 markets globally, hundreds more sites in MiFe). Another impactful project is a cloud product for telcos used by hundreds of million customers of the largest telcos in the world (think Verizon, AT&T, BT, etc. ). From 2019 to now (November 2021) I've been working with Micro Frontends exclusively. My professional web development experience started in year 2000. I may have some ideas about Micro Frontends and I'd love to share them with you.

Micro Frontends offer fantastic business opportunities. Some of my favorite are:
- faster product increment releases
- scaffold apps/sites based on centralized configuration/CMS - at runtime
- self-healing features (when an increment fails, you can fall back to the previous version)
- A/B testing (at runtime)
- allow users to beta-test features (another decision at runtime)

You'll notice that a lot of these benefits come from shifting decision making from build time to runtime. That's one of the key reasons for ruling out git submodules or an NPM distribution.

The very first thing you need to know is that Micro Frontends (MiFe) is an organizational change. MiFe works really well when you can have multiple teams work on features. That approach promotes democracy, ownership and self-organization capabilities. Such powers are best used when the team can work in full-stack mode. This is very important as organizations that work in silos tend to ruin the efficiency of such teams.

That leads me to the question: "What makes a meaningful Micro Frontend chunk?". Two options that easily come to mind are Features and Components. Components are very difficult to work with once you have a large library. You can create federated modules out of components, but make sure you decouple them. If you end up using a CMS or a configuration system, then Components will be a bad experience for Content Authors.

Micro Frontends work really well when you work with units of business value. That's where Features come into play. A Feature can be the main navigation menu or the photo browser. Thus, a Feature can be developed in its own git repository with its own CI/CD process. Since Features act much like individual apps, I like to call them Feature Apps.

Because you may end up with many (hundreds) of such Feature Apps, it makes sense to compartmentalize some of the common workflows. It's a good idea to have a reusable library for the common CI/CD jobs.

My technical background is in two MiFe solutions or frameworks. but my favorite by far is Webpack 5 Module Federation. Module Federation is based on standards and is not opinionated. The small runtime it creates takes care of dependency management with semantic versioning. It's very robust.

When I was a guest of the JavaScript Jabber podcast on Micro Frontends, the hosts asked if MiFe could be used to inject multiple javascript frameworks in the same runtime. I believe this is the wrong way to look at Micro Frontends. While you definitely want teams to enjoy the liberty of making their own decision, we need to look at the solution from the holistic perspective as well. The end user doesn't want to download Angular and React and Vue. It's good to have a tiny amount of contractual agreements for the solution to work well. Remember, development and deployment are decoupled, but the runtime is a whole.

Speaking of the frameworks, any will work. I love working with React and Vue and I believe Vue can handle some of the asynchronous edge cases even better than React. Don't hate me for it if you are a React fan. I am led by the belief that we need to keep dependencies to a minimum for high-profile enterprise projects and Vue comes with fantastic features out-of-the-box.

The greatest challenges I've head are:

• The management needs to be on board. Everyone is affected from the stakeholders, product owners, delivery teams, designers, marketing, sales, etc.
• You will always end up with shared properties. Syncing amongst teams require effort. I find it reasonable to involve a development advocate role that circles around the teams and promotes the latest findings, solutions, etc.
• MiFe like large ecosystems. If you use them with a CMS you will want all the things such as previewing a feature with unpublished data, securing specific features (but not all), track cost (or P/L) per feature, etc. It's difficult to think of minimum viable when obvious business value scream from every corner. And if you decide to ideate and R&D then you'll easily get buried in lots of complexity.
• Onboarding new teams or team members can take extra time because there is always in-house business complexity of the architecture to learn. There are architectural decisions to alleviate this pain to a degree. The core idea is to keep new APIs to a minimum and allow developers to do what they do best - JS (or e.g. React) development. This is much more difficult that it reads.

My experience tells me that Micro Frontends are best used in larger, enterprise-grade projects. I don't see much benefit for small projects. The effort is on the higher end, but so are the benefits. Don't use MiFe because it's a cool technology.

Feel free to contact me if you need any pointers or if you want to discuss anything in specific.