The frontend experience of the web is an integral part of our lives, whether we notice it or not. The evolution of frontend practices and technologies are generally imperceptible by the average user. Web browsers silently improve, applications magically appear with new functionalities, and mobile apps are automatically updated behind the scenes. This is all thanks to the daily work of frontend engineers who try to apply more efficient technologies and tools towards a better Internet for all.
Micro-Frontends: The Best Approach to Managing Monolithic Apps
The frontend experience of the web is an integral part of our lives, whether we notice it or not. The evolution of frontend practices and technologies are generally imperceptible by the average user. Web browsers silently improve, applications magically appear with new functionalities, and mobile apps are automatically updated behind the scenes. This is all thanks to the daily work of frontend engineers who try to apply more efficient technologies and tools towards a better Internet for all.
Micro frontends are the next wave of change which will further increase the efficiency and speed at which we build the web. By separating a large scary frontend project into smaller, manageable chunks, small teams of people can be responsible for components in the architecture, rather than for the entire architecture itself. Micro frontends even make it possible to use completely independent technologies and tools.
What Did Microservices Come From?
There have been many key milestones that allowed for more efficient application development in the past. Notably, the current architecture of separating frontend and backend allowed teams to utilize different tools and skill sets to maximize business logic vs. page rendering.
This approach first prompted backend developers to consider the further disintegration of the systems, which resulted in the creation of microservices. The idea of microservices was to separate the backend into smaller pieces responsible for a smaller part of business logic, and then make them communicate with each other. It gained popularity mainly in large projects, where the introduction of a change to the production environment sometimes took months, due to the fact that a change in one part of the application implied a number of changes in many other places that, obviously, should not depend on themselves.
Microservices communicate with each other through an interface, so it was enough to make sure that the interface (API) was still the same after making changes, which can be easily achieved thanks to the usage of tests.
Micro-Apps Take Notes from The Backend
It is no surprise that modern micro frontend architectures very closely resemble the backend, where semi-independent microservices operate individually.
The earliest versions of micro applications consisted of creating modules, where each module is a separate application. This solution is helpful because it allows many teams to work without conflicts. It has a positive effect on efficiency, as each team is responsible for a smaller piece of the application, which increases the confidence of each engineer.
However, this solution also has one big disadvantage. Because each module is an independent application, it is inevitable to repeat parts of code responsible for key actions (e.g. log in). You can separate such code into individual libraries or packages, but then versioning takes place - you have to remember this in every application that uses the library or package. You must also remember that such a package should be compatible with all our frontend applications and that it imposes certain limitations.
There is a more elegant solution: micro frontends.
How Micro-Frontends Work
Micro frontends are simply frontend applications that are only a small piece of the larger application. When architectured together, micro frontends give the impression of one large, seamlessly constructed app. The difference is that the components are micro applications from which the final platform is built.
One main application, the so-called macro application, is responsible for the composition. The task of the macro-application is to load the appropriate micro frontends based on the current URL and compose an appropriate architecture from them.
The great advantage of this solution is its versatility. A micro frontend can be an application written using popular JS frameworks such as React, Vue, Angular, but it can also be an ordinary static HTML page and, even more interesting, we can combine it all without breaking anything.
You may be wondering why it’s valuable to combine different technologies together. So let's take an application that was created with separate modules as an example. Each module was created at a different time and developed by a different team of programmers. It is very likely that over time, new tools and new frameworks were implemented, and over time it resulted as a technological mish mash. Nothing stands in the way of using a micro frontend solution here.
There are two steps which are necessary:
- Create a macro application that will be responsible for loading the appropriate micro frontend.
- Adapt modular applications by running them through a macro.
The first step is creating a new app, which is fairly straightforward. The second step seems to be complicated and time-consuming. In fact, customizing the application comes down to exposing a specific interface that the macro will use to initialize the micro application. This interface can consist of, for example, three events: bootstrap, mount, unmount, which correspond to the application life cycle and are called during initialization, mounting and unmounting when the application is not needed.
With the application prepared for launching as a micro frontend, you can extract successive portions of logic into separate micro applications and arrange them like blocks in a macro application.
Every developer has likely encountered an application so large that it took a couple of minutes or even more to run the tests. After a few days of testing such an application, you wonder what can be done to speed it up. You can only run some of the tests, or temporarily disable tests which are not needed. Of course, this carries some risk. For example, before release, we will not run all the tests and it could turn out that something has gone wrong somewhere. Having a micro frontend, which is generally a smaller application, we also have fewer tests to run, so we are not slowed down. We run tests more willingly and more often, which also results in better quality.
Thanks to the proper usage of the micro frontend architecture, we can achieve better performance as well. The macro application decides what is needed at a given moment and we just load it. It's easy to prioritize what loads first and what might wait.
Micro frontends are small applications, so a separate deployment process can be used for each of them. For some it may be a disadvantage, for others just the opposite. A separate process means additional work that needs to be done, but nothing prevents you from extending the current pipeline with additional steps to build and send the application to the appropriate environment.
There are some problems with loading several JS applications. One of them may be the error reporting, usually desirable in large projects, where it is more complicated to configure appropriate reporting by sub-project.
Get Started with Micro-Frontends
The microservice architecture has existed since 2016 and quite a lot of materials have already been created to improve the implementation of this technology. I encourage you to familiarize yourself with the single-spa.js library, which allows you to transform the majority of the most popular JS frameworks into micro frontends. You can also use a ready-made Qiankun solution that will allow you to use micro frontends with ease.
Finally, you should pay attention not to blindly follow trends and always consider the pros and cons of each technology. Not every solution will be right in a given situation. Micro frontends work well in large and long-term projects where a lot of people are involved and you begin to feel disturbed by each other. For smaller projects, it may be better to consider the standard approach.
On-demand webinar: Moving Forward From Legacy Systems
We’ll walk you through how to think about an upgrade, refactor, or migration project to your codebase. By the end of this webinar, you’ll have a step-by-step plan to move away from the legacy system.
Latest blog posts
Ready to talk about your project?
Tell us more
Fill out a quick form describing your needs. You can always add details later on and we’ll reply within a day!
Strategic Planning
We go through recommended tools, technologies and frameworks that best fit the challenges you face.
Workshop Kickoff
Once we arrange the formalities, you can meet your Polcode team members and we’ll begin developing your next project.