Micro Frontend
Disclaimer: The content of this blog are my views, observations and understanding about the topic based on my personal experience.
What are Micro Frontends?
It is a domain driven design approach, where we divide a big domain into small sub domains and then we design our solution around it. It is basically extending the idea of microservices architecture pattern to frontend development.
Objectives of Micro Frontends
- Incremental migrations and rewrites
- Independent release schedules for your teams
- Allow technical decisions to be made by individual teams
Approach Revolutions
In the diagram 1.3, we are interacting with various micro services (like MS1 and MS2) to front end and vice versa.
Diagram 2 represents the horizontal team. The micro front end approach suggests having vertical teams consisting of people from frontend, micro services, business, operation, etc. This vertical team has its own goal and its own business problem. In this approach, the team can move faster as compared to the horizontal team approach because the teams have limited area to play around and hence, they innovate in a better way.
Lots of companies are following this approach – Netflix, Spotify, Facebook. They form squads which represent vertical team and tribes which represent horizontal team (like Front end, Micro services). You have to focus on your squad and can communicate with your tribes. Here each team can have its own technology which serves their business problem.
For example: ‘Product Team’ can develop their frontend portion in an angular, likewise ‘Search Team’ can use React and ‘Payment Team’ can use Vue js.
Why Micro Frontend?
Micro frontend is an architecture pattern and style where independently deliverable frontend applications are composed into a greater whole. You would probably agree that a single framework cannot give the best solution to all problems. Each framework has its own pros and cons. The additional approach is not helpful for larger application, or larger teams (around 20k+ members).
Benefits
- Easy migration – Helps us to migrate in bits and pieces
- Simple and decoupled codebase – Each team will solve limited problems so codebase will be simple and since we are working on micro services pattern we can decouple our codebase.
- Reduce communication overhead – as we are solving limited problems, communication overhead is reduced.
- Independent release – One team can release their version 2.1 (with some new features in their sub domain) and other team is at version 1.6 this can be possible.
- Innovation area – Suppose your project has been started 2 years ago and at that time a certain framework was better, but now with the new requirement you realize this can be solved in much better and easier way with some other framework. This can be with micro services framework principle.
- Can solve specific business problem
- Reusable smaller fragment/ component
- Micro app/component/fragment can be independent and isolated
- Minimum dependencies
- Technology or framework agnostic
- Easier to understand develop, test and deploy
- Faster and reliable CI/CD (continuous integration and continuous deployment)
Disadvantages
- Size will increase due to library because all micro service frontends have its own library, so you have to inject all dependence/library individually. This will be resolved soon with the module federation where, by writing our webpack we can write module federation config and we can decide reusable packages and dependencies.
- Redundant code – Component which is going to be using in each sub app
- Operational and governance complexity – For other applications, it is easy because there will be only one pipeline where code checkout, test suite runs, and jenking runs. In micro services application there will be multiple application in it that have their own pipelines, so the governance of buddle size, CSS compression, test coverage can be difficult
- No standard way- there is no certain way do it.
- Not recommended for simple application
How to migrate legacy app
There will be any other better way to do it. I found this:
- Separate common components like header, footer and navigation
- If not, then create separate route for each component (like Product, Search and Payment should have its own route)
- Now create sub app for each component which is having separate routes and you can develop sub app in different frameworks (like Product sub app developed in Angular, Search in React and Payment in Vue js)
Problems to solve
- Cross-application communication – communication between micro frontend. It can be done with window object, local storage, redux global state or any other like these
- Backend communication – can be resolved with BFF technic (backend for frontend technic), so frontend will communicate with its BFF and it is BFF’s responsibility to give response to frontend which can be sum up of one or more micro web services.
- Testing – Micro service front end application testing is difficult as compare to other.
- Common content – This can be resolved by story book
How to Implement
Frameworks to implement:
- Single-spa
- Frint JS
- <iframe>
- Web component (Angular elements)
- Reverse proxy (like nginx server, load balancer)
POC
I did a POC, You can find it here https://github.com/neerajrathod05/Microfrontend-Example-Message-
Software Engineer at Innovecture
I work on Front End Technologies. Apart from that I enjoy traveling, going to parties, and recently started blogging. To know more about me, find me on social media!
