“Software architecture should never be an end goal, but a means to an end”
I write this blog from the perspective of an inexperienced learner and hence the language adopted here would be in the layman’s terms making it easier to understand.
We begin with the most obvious and important question that one should know the answer to before studying the applications of Micro frontend, i.e. what is meant by the term Micro frontend.
Micro frontend is basically a term for Self-contained Systems or Frontend Integration for Vertical Systems which simply refer to an idea that considers a website or a web app as a composition of features which are owned by independent teams. Each team has a distinct area of business or mission it cares about and specializes in. A team is cross-functional and develops its features end-to-end, from database to user interface.
Now we consider the secondary question: How would using micro frontend development architecture over the traditional monolith help the developer?
The answer lies in the fact that though monoliths are easier to design and the area unit is simple to deploy, monoliths provide limited agility because even tiny changes require a full redeployment. In addition, I understand that monoliths usually find themselves trying a huge ball of mud of sorts as a result of the software system evolving over time. All these points and more are addressed when we go on to consider the key advantages that micro frontend architecture has when implemented in an enterprise setting which are as follows:
FLEXIBILITY: Since each team has autonomy over their fragment, they are free to use whatever frameworks or languages they prefer.
TESTABILITY: By separating a monolithic site into small stand-alone fragments, we narrow the scope of the tests that are to be conducted. This specifically makes testing easier and allows for confidence on deployment.
SCALABILITY: Another benefit of the modular nature of the micro frontends is the ease with which growth is possible. Other teams can be easily created as the site evolves, which allows for faster on boarding since new team members only need to learn about their feature instead of the entire codebase.
PERFORMANCE: None of these matters if the user’s experience suffers, but micro frontends can help us there too. Since a page is now made up of a bunch of fragments, one slow loading piece of puzzle won’t hold up the entire site.
Now we move on to the specific applications that this structure holds in the context of OpenMRS.
First let me specify what exactly is OpenMRS;
It is a collaborative open-source project to develop software to support the delivery of health care in developing countries. Although all of the advantages specified above would still accrue to the Open MRS, its description holds the key to the most reason as to why we need Micro front end for the development of the software. As it says OpenMRS is meant to be used by the people all over the world which means that it needs to be easy to understand which in turn basically translates into having an amazing GUI for the software. Now if the software were to be designed using the Micro front end structure then designers would gain the opportunity of focusing on a very specific part of the Frontend while leaving the rest to their team. This would in turn help them achieve the required quality.
Thus the user would leap ahead and have an edge on others. Micro front end is truly the need of the future.
- K Walia
Sources:
from the writings of Michael Geers , Rahul Gaur and John Eckert.
https://micro-frontends.org/https://dev.to/aregee/breaking-down-the-last-monolith-micro-frontends-hd4
http://www.eikospartners.com/blog/author/john-eckert
Comments
Post a Comment