Microfrontends: the good, the bad, and the ugly
In the last couple of years, microservices have become very popular among developers and who haven’t heard the phrase “killing the monolith”. As the products and applications scale and become more complex nowadays, building the products in a service-oriented architecture style has become more and more common. Instead of the typical monolithic structure, you have several individual services that can run on their own and together delivers all the functionality that was previously served by one monolith.
Now that the microservice term has become nearly the standard for new backend services the focus has been moved over to the frontend. There has been a new buzzword in the frontend communities the last years, that is microfrontend. The term first came up in ThoughtWorks Technology Radar at the end of 2016 and has now since the beginning of last year been recommended to be adopted. How should you and your team start using it and what are the best practices of using this architecture?
At my client, we started to adopt microfrontend last year and we have gained some experiences about when and where there are benefits of using it.
Independent teams
The one benefit that is often mentioned in relation to microfrontend is that one single team can work on one specific functionality. This means a team of both frontend and backend developers. Each individual team could therefore build the functionality based on different languages and technologies but together works as one solution.
In the illustration above you can see how this should work. Each team has the functionality to work on, for example, search. This means that the search team would deliver the search functionality from an input field to the actual search in the database. The best practice of the microfrontend technic, in this case, would be that the other teams do not care about what kind of framework this team is using.
Scaling applications
When developing new products or extending existing ones with additional functionalities a common approach is to start by developing a minimum viable product (MVP). This means a version of the product that has sufficient features to satisfy early adopters.
In some cases, the MVP would just be a very small part of the final product. The problem could then be that the final product would be huge and increase the complexity of the application. The microfrontend technic solves this problem in the way that we can run the MVP as one single application instead of extending the existing one. It also gives us the advantage to divide the MVP if necessary into multiple applications to reduce the complexity.
Interaction
In many cases, the microfrontends can work independently without knowing anything about what is happening in other places in the application. However, it may be necessary with some sort of communication between them. This can be solved in multiple ways. One of these may be to make use of an event bus layer.
What is an event bus? An event bus is a mechanism based on an event-driven architecture pattern that allows applications to communicate with each other without knowing about each other. This means that one application can send an event to the event bus and another application can catch the event to trigger something else.
User experience
Another important part of having a solution based on the microfrontend technic is to have a complete user experience throughout the application. This means that the user should recognize the elements, colors, and texts used in the design. To accomplish this a component library and a design guide are a necessary part.
A component library is like a design guide, but for both designers and developers. It often has a wide range of multiple components available to the developers and works like building blocks when creating a new solution. This means that in the library the developers should find basic web elements like buttons, inputs, and lists. The component library is then maintained by both the designers and developers with improvements, bug fixes, and new implementations.
From my experience with my client, this was one of the most important parts to have in place before going completely into a microfrontend architecture. A component library makes it easier to maintain a holistic design and user experience, and especially when there are multiple independent teams working on multiple frontend applications to build one solution.
Conclusion
So, should you and your team implement a microfrontend solution? It depends on how your current and future solution would look like. Microfrontend should not be the architecture goal for smaller applications and can make the solution more complicated than it should be. If you have a large application that is going to be extended with even more complicated solutions in the near future and is also starting to be too large for one single team of developers. Then you should strongly consider a microfrontend architecture. But one thing that I highly recommend you to have in place first is a component library.
