We all familiar with the term Micro Services, lot of organizations adapted this pattern to decompose their monolith back-end applications in to seperate entities based on their functions, that can be coveniently developed, tested and deployed with lot of other services.
While the Front-end mostly kept Monolith.
Now what if we apply this pattern of decomposing a monolith Front-end application to many pieces of Front-end applications?
- A company with lot of experience on CRM applications developed with an very old legacy Native HTML, CSS and JS wants to taste the Latest Angular or React
- A complex food ordering and delivery company with a Front-end that handles ordering, delivery and listing restaurants with their foods needs to manage the code base complex free among various teams working on the same monolith Front-end
Now the question arises, how these different blocks of front end applications route among themselves?
There is one such example as the Thoughtworks article discusses with the term as follows
- Adopting this pattern can lead to much smaller source code of each individual micro frontend than that of source code of a single monolithic frontend.
- These smaller codebases can be simple and easy to develop for developers.
- We can avoid the complexity due to unwanted coupling between components that needs to be hidden.
- Increased Payload size due to different JS bundles. Solution: The integration team should know about the possible bottlenecks
The situation where multiple teams working on differnt components face a co-ordination crisis
Solution: An intense Test driven Production like deployment cycle must be followed before the actual production deployment
Final thing is to consider is how we are going to manage when the Micro Frontend components gets increased in numbers?
Support Us: Buy Me a Book
Explore more on dogealgo