Micro Frontends - Part 1: What and Why

“An architectural style where autonomously deliverable frontend applications are created into a more prominent entirety”

Micro Frontends are extensions of microservices architecture and aim to apply the same principle to the frontends.

           

In the early days of software development, both the frontend and backend components would be bundled into one application which we now call it as a monolith style of application. Physically this type of application can live in one code repository. And that code repository would contain directories for frontend and backend part of the application but it was a one large solution which contained UI and business logic which would be maintained by one large team.as the Monolith are huge, changing anything would be taken seriously as testing and deployment was a huge task as the impact of breaking anything else that was unrelated to the change.

Frontend and Backend: The industry soon realised the advantage of breaking the frontend and backend and at the same time we ended with separate teams that specializes in backend development and front end development. Things generally improved with the split but the backend teams started to suffer with scaling issues as the business logic , functionality and data grew so did the size of the BE. so when we started to realize that one backend system in the form of API and services had to serve multiple different types of frontend in the form of mobile application and web applications something had to be done to address these issues. 

So the solution of the backend system was to use microservices architecture to split the large monolith applications into smaller services and api’s each with the clear scope and responsibilities. And each microservice had a dedicated team that specializes within that services responsibility in terms of domain knowledge. And the frontend team would call different api’s for the different part of the frontend application and this would have been done via API gateway or a backend for frontend(BFF) API which would talk to other downstream microservices

So in last few years we realized that microservices at the backend resolved these scaling issue and now we have issues at the frontend side of the application

                       

Microservices design principles (same can be incorporable for frontend)

1. High Cohesion - each microservice has on responsibility and focus . I does one thing and does well
2. Autonomous - Each MS can be independently changed and deployed
3. Business domain centric - MS has one single focus but also represents specific business domain or function within the organisation
4. Resiliency - even when there is failure, the system is resilient failure. It tries to fail fast and embrace the failure by defaulting or degrading the functionality
5. Observable - Using centralized logging and monitoring see what each component is doing.. Also monitor the health
6. Automation - automate using the tools for independant testing and deploying

Problems with Monolith Frontends:

1. Scaling issues - with the architecture and the teams, the codebase has gone so large and intertwined so making small changes takes longer. Instead of scaling one part of the application you end up scaling the entire monolith. Also needs large team to maintain the application which means a small change needs a lot of coordination
2. Communication issues between large frontend team and backend teams for simple ui change as  the priorities of the teams will be different

3. Code and testing complexity can increase the risk of managing the monolith applications
4. Slow continuous delivery

           

Advantage of Monolith frontends:

1.     Single code base

2.     Easier to setup for testing and development purposes

As the monolith frontend codebase grows over time:

What Increases:

1.     Dependencies - FE dependencies on internal and external 3rd party libraries/components grows which also increases the overall complexity

2.     Team size:  to maintain the growing and complex code base the team size increase

3.     Coordination: as the size of the team increases, the coordination required to make a small change increases

What Decreases:

1.     Ability to Change : ability for adapting a change slows due to the coordination effort required, also the technology used in frontend becomes older and more stale as the project ages.

2.     Staff availability: As the tech stack and tech choices become stale, the availability of staff with a specific skill in the market also decreases.

3.     Innovation and releases

The above problems can be described with a graph of “Law of Diminishing Returns”

 

Micro Frontend to the rescue

The approach is quite similar to BE, we take our large application and split it into a smaller components, however there is a lot more for Micro Frontends approach than just splitting. We try to make our software vertically sliced end to end, which means our micro frontends are inline with supporting backend micro services. Each vertical slice is basically a end 2 end feature.

For example: 

Within your web app, you have a cart section which is an end to end feature in the form of a micro frontend which is a cart section and in the backend it has a microservice or number of micro services which support that micro frontend and this entire feature is owned by one team which supports, maintains and develops this feature end to end which includes micro frontend also the supporting microservices in the background and any storage associated with each one of those services. 

This type of vertical slicing and team ownership of end to end feature means we inherit now the benefits of microservices and we can now independently change, deploy feature end to end without affecting the rest of our application. If we have specific performance issues we can focus on scaling out that aspect of our application. We also now have the clear end to end ownership of the features within our applications. Also the team has the domain knowledge as they own the complete feature.

One of the key aspect of the Microservice architecture is to give the illusion of one unified application and not to give away the fact that the application is actually made up of multiple micro frontends. The most common scenarios to achieve this is to use a base app which is basically a shell housing our micro frontends. So the base app or shell or browser they interact with each other giving the user an illusion of one functioning application that's consistent and coherent.

In the next article we would be talking about Micro Frontend Design Principles.