You should consider Micro Frontends
Micro Frontends is an architectural style to allow many teams to work simultaneously on a product. So if have multiple teams trying to work together on an application, you should consider Micro Frontends. Or maybe you forsee there will be a large number of Frontend developers working on it, then you should really consider it.
Micro Frontend Techniques
| Technique | Type | Description |
|---|---|---|
| Template composition | Server-side | Rendering HTML with multiple templates/fragments (ie. multiple server serving HTML files) |
| Library | Build-time | Have each micro frontend as a package and use them in a container application |
| iframe | Run-time | Use iframe for each micro frontend |
| JavaScript bundles | Run-time | Bundle each micro frontend as JavaScript & mount the one when needed in container application |
| Web Components | Run-time | Using a set of JavaScript APIs to render custom elements as micro frontend |
Run-time techniques provides the most flexibility.
Why use Micro Frontend?
- Incremental upgrades (ie. evolve large codebase without rewrite)
- Simple, decoupled codebases (ie. easier management)
- Independent deployment
- Autonomous teams
The benefits mostly for organizing independent work & ownership between independent frontend teams and it will hugely benefit for working with external frontend team.
Why you should not use Micro Frontend?
- User experience
- Operational overhead
User experience
Maintaining a consistent user experience will be a lot more difficult.
- Loading of different JavaScript bundles
- Visual inconsistencies (ie. branding, styling, etc)
- Having different life cycles of each micro frontend makes maintaining a good UX difficult (ie. waiting for deployment for integration)
Using micro frontends in a consumer application will incur a huge risk of poor UX unless we are talking about distinct experiences like the different products in G Suite (ie. Google docs, Google sheets).
Also, if we are using the same technology, why do we need to introduce unnecessary complexities?
Empiricial evidence: Spotify has moved away from micro frontend architecture, saying
The micro frontend architecture had it’s perks but the downsides outweigh the upsides unless you need the sandboxing for third-parties.
Implementing micro frontends will mostly sacrifice UX and forces developer to handle unnecessary UX problems for the sake of breaking the application up. It would be best to have a team who takes ownership of taking care of
Operational overhead
- Maintaining multiple repos
- Micro Frontend is not a widely known architectural style so it takes time to on board developers
Consider the fact that each micro frontend will have their own CI/CD and source repository, there will be complexities over the following:
- Dependency management
- Security
- Governing coding styles & quality
- Testing
Specific challenges
You should consider if micro frontends would really benefit your team especially for the following functions:
- service workers
- navbar
- authentication (ie. shared user session/state)
- browser storage
- sharing logic
- sharing UI components between different
- server side rendering
- behaviour tracking
- deployment