Micro Frontends got really popular in 2019. I really enjoy seeing all of these efforts aiming to bring maturity to front-end development! However, the concepts behind it are not new. The novelty here is the proper definition of the method and its formalization under one title.
There are many articles about Micro Frontends around, so why would you care about this one? Well, here we will focus on its Front-end Architecture point of view.
Architecture, however, can be a vague word. Its most common use in our field refers to low-level concerns, such as System Design, code organization, and so forth. But I prefer to call these things for what they are: “System Design”. That allows us to reserve the word “architecture” to refer to higher-level concerns like Software Architecture does.
System Design is very important, but it shouldn’t be our only care while trying to make front-end projects successful. The strategic high-level guidance brought by architectural work is essential to make front-end apps survive on the short and long terms… but is frequently neglected by front-end professionals. You can read more about it here.
So, you know that this article will discuss Micro Frontends from the Front-end Architecture perspective. But what is Micro Frontends? Please consider this puristic definition:
“Micro Frontends is an Architectural Style where a frontend application is split – based on business logic – into two or more sub-applications so that multiple teams can work on them concurrently, each with full ownership of their piece, including decisions regarding tech stack, development environment, maintenance, and deployment processes.”
Fabio Nolasco
Micro Frontends offers a model that allows for independent:
- Teams
- Tech Stacks
- Source code
- Testing
- Repositories
- Deployments
Now, in the real world, we often need to adjust the methods we choose for our own situations. Many people, for example, might follow all of the criteria mentioned above except taking control of the deployment processes. Others have centralized repos. Nonetheless, the strongest underlying idea of Micro Frontends is to have the main application split into sub-applications so that different teams can work on them independently. These pieces are then brought together and orchestrated under the umbrella of a base/parent app.
Looking at those images, it might feel that Micro Frontends is the latest evolution of Front-end Development… like that image showing humans evolving from monkies. But that is certainly not the case. Micro Frontends is just “a” solution and has very particular use cases. Here are some pros and cons to consider before we jump into the architectural concerns.
- Pros
- Less complexity (the complexity is split into multiple sub-apps)
- Smaller chunks of code (sub-apps)
- Easier and faster to read
- Easier and faster to change
- Fewer chances of mistakes
- Development speed: concurrent development of sub-apps
- Changing one sub-app does not require touching the approved code of other sub-apps
- Easier upgrade of the underlying technologies for each sub-app
- Independent testing
- Faster to run
- Easier for us to be more thorough with it than on a huge system
- Independent deployment
- Faster to process
- Allow us to fit the best the technology to each need (sub-app)
- Cons
- Increase of duplicated code
- Increase the final product size (kb)
- Difficulty with versioning of the sub-apps
- How to keep track of their compatibility?
- How to put safety guards on deployment so if we roll back one sub-app, the other sub-apps might be adjusted accordingly?
- Increased difficulty in managing data flow and side effects
- Possible difficulty with debugging (where did the issue occur?)
- Server-Side Rendering can be made more difficult or impossible
- Possible difficulty on managing the list of API endpoints across the multiple sub-apps
- Increase in the number of dependencies
- Difficult governance of dependencies across multiple sub-apps
- Which libraries are being used?
- Which libraries are have been deprecated?
- Which libraries need an emergency security patch?
- Which license each library has?
- Mode difficult for the independent teams to spot opportunities for reusability
- Possible challenges with UI/UX consistency
- If communication is one of the TOP sources of bugs, will this splitting of the teams lead to more challenges?
- Observations (remember)
- We might be able to deploy each sub-app independently, but the testing (Integration and E2E) would still need to occur every time
- The complexity of the code os each sub-app will reduce, but the efforts of coordinating the usability and the data flow will increase substantially
- Supposing that the sub-apps use a similar dependency and that we need to update it… now, instead of one change and one deployment, we will need to perform multiple changes and multiple deployments
If this was an Engineering article, you would be seeing many other contents, such as (a) how to bring all o the sub-apps together, (b) which libraries or frameworks can be used on the parent app, (c) strategies for data flow, etc. However, here we want to investigate the criteria that we should use in order to make an educated decision on when to use Micro Frontends.
One of the most risky aspects of ignorance is how it can make us confident in poor choices.
Fabio Nolasco
Architectural decisions are expensive decisions. Changing a for-loop to a while-loop or a recursive function is not usually expensive. As architects, we are expected to leave those to creative and intellectual liberties to the programmers. Now, if something is expensive to change later on, we should certainly take our time collecting information, meditating, and talking about it. Only then we will be able to take high-quality educated decisions. Just exemplify what I am talking about, here are some questions that I would consider while investigating Micro Frontends:
- What other options are there for Architectural Design in frontend besides the three options: Monolith vs. FE/BE vs. Micro Frontends?
- Which challenges will Micro Frontends introduce?
- Which cultural changes will it bring? Will my coworkers be able to adjust?
- Are we being fully honest regarding the pros and cons? Or is the hype still playing any part in our decision making?
- Could it be that by working on even smaller pieces of code the developers will have difficulties understanding the big picture, and therefore feel less engaged or interested in their work? (Remember the side effects of the production lines of Henry Ford) – Could it also discourage or affect ideas for innovation?
We need to beware of the “Spark Plug Effect”. Things that for us might seem a detail can carry a lot of power, being the deciding factor between success and failure. For technical people, it is easier to spot those “spark plugs” when they refer to technical things. But when the “spark plugs” are subjective or conceptual, technical people might not give it the proper importance.
Less experienced architects and highly technical-minded people, like programmers, could have difficulty understanding how cultural changes and communication would have a deep impact on the success of software development and software products. But they do, a fact that is well established by researchers and supported by data and professionals of the field. So we need to be careful to do not let our teams to always try to solve our challenges with yet another technically related effort.
Micro Frontends is a great solution… when it is the right fit. Otherwise, it can harm your productivity and the quality of your products. As architects, we need to be cautious against hypes. We must perform proper evaluations of the ideas presented to us and take our time to really think of their most varied implications. Hopefully, this article helped spark some ideas in you!