Most developers have already heard about microservice architecture, but micro frontend is a much lesser-known term. As the name suggests, micro frontend is similar in concept to microservices. It attempts to solve many of the same issues that monolithic applications present. They’re too big, hard to work with, and difficult to make changes to. Onboarding new people to work on them can be a pain. Also, if multiple teams of people are working on different parts of the application, they’ll need to coordinate all their changes with each other.
Microservices help you split the backend into more independent services. The same approach can be used to split single page applications (SPAs) into smaller apps, with the additional need for an “orchestrator” that can put different parts back together so that the user is still experiencing SPA behavior.
What Are the Alternatives to a Micro-Frontend Architecture?
Of course, there are other ways to deal with some of the undesired aspects of huge applications, like separating part of the code into its own npm package. That can solve part of the problem, like the repo being too big. For example, in Angular, you can also separate code into a module that can be lazy loaded. This can allow for vertical splitting of the application to some extent. But, it also has its disadvantages, like having to build the top-level project when one of the dependencies is updated. Also, the developer experience isn’t that great. When using any sort of framework, it’s a good idea to upgrade everything to the same version, but it’s a huge undertaking that no one is excited to do. You also have the option to join multiple apps together via iframe. It makes them independent, but I’d say maybe too independent as inter-app communication is a problem and so is sharing code, styles, etc.
Micro Frontends to the Rescue?
Micro frontends are a combination of these two approaches. Each micro frontend is a separate application that is in comparison to the SPA. It isn’t compiled to an index.html with linked script and style files but to a JavaScript module. Instead of an iframe in the “main” app, code defines that when the URL is matching some pattern, the module is then lazy loaded and placed in a specific spot. Thanks to this we can have multiple apps on the same page that can be interconnected with each other.
As a result, micro frontends don’t need to handle app layout and basic CSS rules that can only be handled in the main app. Equally beneficial is the fact that if I have multiple micro frontends using the same version of React, then I can have them share the React module. It doesn’t have to be downloaded separately for each micro frontend. Having different versions of a JS module is also not a problem.
The main worry with micro frontends is to make sure that their styles don’t overflow to other parts of the application. Fortunately, most commonly used UI frameworks have tools to handle that with ease.
Tooling for Micro-Frontend Architectures
Writing your own code to load micro-frontend applications would be quite a task. Fortunately, there are multiple frameworks that handle orchestration and offer tooling to convert apps written in the most-popular frameworks to the micro-frontend format.
At Pure, we chose single-spa. The main benefits we’ve found are that it’s easy to understand, offers wide support for JS frameworks, and has detailed documentation. In addition, single-spa offers multiple types of micro frontends, each suited for slightly different jobs.
At the moment, we’re only using “Application” type because it’s the easiest to use for moves from SPA to micro frontends. Other types also require more detailed micro-frontend architecture. Also, “Application” is recommended as the default by the single-spa authors.
