Micro Frontend Architecture — 5 reasons you should break your frontend
Many years ago, we had a monolith application. The Backend and the Frontend were together, same repository and, usually the same base. There were applications that even the database logic was together. I remember to work in a .NET application; the frontend part was made on ASP.NET, with some C# code for logic and no stored procedure, just some line of SQL on the C#. It was chaotic.
After a while, the concept of layers arrived in our world. At that point, we sent the stored procedures to the database; we created a business layer where all the code where present and finally the presentation layer, written in ASP.NET.
But the Back End walked an extra mile and created the microservice architecture. At this point, as also introduced the services and I remember to leave the Backend part and focus on the new Angular JS. It was a new world, specifics part of the Backend were deployed with no change on other components.
And now it is our time; the Frontend is now taking the step next step with the Micro Frontend Architecture.
The Frontend Architecture says that you can have many applications running together in a way that the user does not see this division. So in the end, you will have one application face with many micro applications running behind.
Why should you use a Micro Frontend Architecture?
You probably are asking why you should apply this architecture? And there are several reasons to do it like:
- Frontend Size, with a Frontend monolith you will have a unique repository, which can sound like good news at first but it is not. To have multiple small repositories is a better situation, as the developers take less time to get into it.
- Maintainability is increased as you have small repositories, it will be easier to debug and find issues on the code. As also the team working in a specific repository will have a better know-how about the code.
- Dependencies should be close to none, which mean that the deploy of specifics part must be possible affecting no other teams, making the coordination between teams an easier job.
- Team’s size also decreases, as the code tends to be small, the team member also tends to reduce. Of course, you will need more teams than before, ideally one per Frontend division, but they will be smaller and faster.
- Technology variation and update, as depending on the technique you will use, there is also the advantage to have many technologies or versions running together.
