Fighting with Monolithic - MicroFrontends
What are MicroFrontends
All these years we worked with microservices and we are aware of how widely the architecture is adopted . It helped teams to work independently and provided the liberty to choose their preference of language and platform. It eliminated the pain with merge conflicts and provided independent repository to work with. The deployments became much more easier and changes made by some other team would never break our code. However UI teams always worked on a single big repositories. All of the code had to be put together, merged and deployed together. Multiple teams had to communicate together on what versions of React or Angular they are using so that their version doesn't conflict with someone else’s code.0
As you can see above, in a typical application we have multiple microservices connecting to single frontend. Since UI is still a single piece, all UI services would be handled by single team. As the product grows the backend can be split into smaller services but UI will keep growing bigger and complex.
To resolve this how about have microservices architecture in frontend. Every team can choose their own Preference of UI technology and they have their own deployments. This will give us all the advantages what microservices have but in frontend.
Why MicroFrontends
We can have multiple teams working on an application without any conflict. Also the best thing about this architecture is that frontend teams can choose the platform of their choice and our microfrontend consumer will seamlessly integrate them without any conflicts. The microfrontend doesn't bother about what technology we use, it will have its own set of rules based on which it will load the desired application.
- UI code is not huge.
This architecture will make sure that you have a small code base. In a eCommerce architecture we can have separate microfrontends for listing , payment and user accounts. So the amount of UI code would be reduced and inturn better performance and maintainability.
2. UI Team can Choose technology.
Frontend teams can choose their own technology, payments team can work with angular, listing can do vue and user account section can do react. The microfrontend consumer doesn't care about the technology is used, it will show user all as a single application.
3. Independent Deployments
If there is a change in listing page we no longer have to redeploy the entire application and run the test suite. Since our listing application can run by itself all we need to do is re-deploy that application. We will avoid breaking someone else’s code or the application going down completely.
4.Upgrading versions of frontend technology
Sometimes upgrading UI technology can be troublesome. Especially lot of teams are still stuck with angularjs as angular doesn't support backward compatibility. Micro frontend can solve this problem where we can now keep the old portal running in conjunction with new one. We can let the old development be as it is in angularjs and all new development could be done with newer version without having any conflicts.
5. Widely Adopted Architecture
All top companies are now moving towards this architecture as it has proven to be very robust. There are multiple ways to implement this architecture however I have a sample code which you can use as a boiler plate to start your own micro frontend application.
Below is my article on how to set your own Micro frontend.
https://medium.com/@jeetu.nayak1/run-with-microfrontend-5afb5b0d40a1
You can use my boiler plate to start your project with micro frontends.
https://github.com/jeetunayak1/Microfrontend