This document discusses microfrontends, which apply a microservices architecture approach to user interfaces. It defines microfrontends as allowing independent teams to own distinct features from database to UI. The document outlines benefits like faster development, clear ownership, and improved delivery speed. It provides an example migration approach from a legacy monolithic application to microfrontends. Challenges with microfrontends like routing and error handling are also discussed. The document recommends using a framework to address these challenges rather than building the infrastructure yourself.
3. In short: they are Microservices architecture that
was adopted for UI needs
To be more specific:
Think about web app as a composiCon of features
which are owned by independent teams. Each team
has a disCnct area of business or mission it cares
about and specialises in. A team is cross funcConal
and develops its features end-to-end, from database
to user interface.
Micro Frontends is…
4.
5. Are they are mature enough?
https://www.thoughtworks.com/radar/techniques/micro-frontends
ThoughtWorks Technology radar:
• Nov 2016 – Assess
• Nov 2017 – Trial
• Apr 2019 – Adopt
It’s not a future tech - it’s a reality of nowadays
7. * Works well only if you apply Autonomous teams
approach
1. You have multiple teams
8. * Works well only if you apply Autonomous teams
approach
1. You have multiple teams
9. Why you should consider this:
• Speeds up new devs onboarding, less things to learn
• Independent, small, frequent, more controllable releases
• Clear areas of ownership, and so less bugs
• Most of the features can be developed by single team, less
coordination required
• Improves overall features delivery speed!
1. You have multiple teams
11. Why you should consider this:
• Speeds up new devs onboarding
• Simplifies hiring
• You get better community support
• Declarative approach reduces complexity of the app
• Better testability and so less bugs
• Improves overall features delivery speed!
2. You want to modernise legacy web app
12. Migration approach (our experience):
Input: Old MPA written on jQuery, Angular.js, ASP Forms, etc…
Step by step flow:
1. Install Micro Frontends infrastructure
2. Create shared page fragments (ex: header, footer) on new framework
3. Re-write 1 page on new framework
4. Send traffic to re-written page via Micro Frontends infrastructure
5. Repeat points 3-4 for other pages
2. You want to modernise legacy web app
14. New challenges from the past
• Routing – when to load which MF
• Error pages handling – shared 404/500/etc pages across MFs
• Local Development Environment – how to develop a piece of
the page?
• SSR – you need some layout composer for page assembly
• Dynamic code loading – load assets for current page first, load
other later
• Shared common logic – authentication, shopping cart,
notifications, etc…
• etc…
18. No! You shouldn’t. There is a framework for it.
App
Shared
Code
client.js
mount()
unmount()
server.js
config ←
Business logic Client side bundle
Server
bundle
(optional)
Assets
Server runner
(optional)
Server API
CDN
19. Is there are any alternatives?
Yes, but we haven’t found them “complete” enough 😢
So we took 2 most powerful solutions & combined them together.
You can find more alternative solutions here:
• https://awesomeopensource.com/projects/microfrontends
• https://github.com/rajasegar/awesome-micro-frontends