Working with Single-SPA Micro Frontend Framework

What is Single-SPA? / What is Micro Frontend?

I am quite sure that anyone who has been working with backend/frontend technologies knows what microservices on the backend side are. Well, Micro Frontend is that, but on the frontend side. Simply put, Micro Frontend allows us to split one giant whole into smaller pieces. It allows us to split one giant monolith application into smaller “user-friendly” parts. Micro Frontend was presented 2016. and it was inspired by microservice architecture.

Monolith vs. Micro Frontend

As we can see in the picture, first we have one giant monolith application and one Team. Since Frontend, Backend and Database members were working as one team, it was challenging and difficult to maintain such a giant application. We saw an obvious problem, and for the first time we came to the division on Fronted and Backend/DevOps team. With that division things were a little bit easier, but complexity was still there as the application grew. The Backend/DevOps team was the first to spot the problem, and in 2011 introduced Microservice architecture. They solve their problem by splitting Backend/Database layer into several logical services. 5 years later, in 2016, Micro Fronted was finally introduced to solve complexity on the frontend side. Now we have fully functional End-To-End Teams, each working on their own part of application, and by merging them together we have a whole, e.g., application.

What are the benefits?

Since we are splitting the application into several parts, each part of the application is developed separately, so the first benefit is obviously faster development. Why? Because each team can release small parts of the application in a shorter time, and with that division, each team has faster continuous integration (CI) builds.

Another benefit is a code reusability. Each team has their own code bases, but they can still share common parts of the application with other teams through, e.g., creating npm libraries.  By sharing common components, style, api service, etc., we are ensuring consistent and reusable code across Micro Frontends.

We all know how complex building applications are, and it is even more stressful if we have a superior constantly over our head. With Micro Frontends, we get rid of unnecessary stress and have fully functional end-to-end autonomous teams.

If we are talking about testing, testing micro-fronted is faster, because we do not need to test the entire application, but only one part of it. So, faster testing time is a big plus.

One more benefit I need to mention is that companies can focus more on quality by hiring experts, even if they are experts in different technologies, because with Micro Frontends it is possible to combine multiple different frameworks into one application.

And these are just some of the advantages of using Micro Frontends.

What are the disadvantages?

When we have multiple teams working on one application, the most difficult thing is communication. There is always a potential risk of lacking communication between those teams, which could then affect the entire development.

A more complex development process as a whole is another disadvantage of using Micro Frontends. Not only development, but also the implementation and testing process. Why? Because if we have for example 10 Micro Frontends, then we have 10 development environments, and you get the point, right?

And I need to mention one more thing - you need to prepare for a lot of research, because I am quite sure that you will be stuck with some specific problem, and then you will be on your own to solve it. There are still a lot of problems that are still not recognized and to which you will not find answers.

What is Single-SPA?

Single-SPA is one of the popular Micro Frontend's frameworks. It allows us to combine multiple Micro Frontends written in one or more different JavaScript frameworks into one application. It is a top-level router which downloads and executes the code located on the active route. The transitions between pages are smoot, so there are no problems with flickering.

Single-SPA consist of the following:

1. Single-spa root config
2. Applications

Single-spa root config

It is a container application which renders HTML page and is responsible for routing. It needs to register applications to know how and when each application needs to be initiated, loaded, mounted and unmounted.

As we see in the picture, we need to import all Micro Frontends into the container app. For local development we need to have different ports for different Micro Frontends to work, and for the production we need to ensure we have the correct path to the main entry point of each Micro Frontend. If we have a Micro Frontend, for example a style guide or authentication utility module which needs to be immediately called, then we call it inside the index.ejs file and load it through the system import.

Applications

Applications are micro-frontends which share the container’s app HTML page and must know how to bootstrap, mount and unmount itself from the DOM.

Layout Engine (single-spa-layout)

It is an NPM package and additional add-on for single-spa. It provides API for controlling top-level routes, applications and DOM elements. It supports easier work with DOM placement and ordering of applications, loading user interfaces, default routes for Not Found or 404 pages, transitions between routes, server-side rendering and error pages.

Types of Micro Frontend

The application is recommended to be used as the primary type of Micro Fronted. The only difference between this and normal SPA application is that it does not have an HTML page. It can be registered in root container, started independently, or registered in some other application. Once the application is registered, it needs to implement lifecycle functions correctly. Bootstrap, mount and unmount are required, but unload is optional.

Parcel is an advanced feature of single-spa framework. It needed to be mounted manually in the application. It can be as big as an application or as small as a component. It can be written in any language if it implements the lifecycle functions correctly. It is recommended to be used only if you use multiple different frameworks in your application.

The utility module is the in-browser JavaScript module. It is neither an application nor a parcel. Its only purpose is to export functionality to import it to other Micro Frontends. It does not need to be registered. It is used to avoid code duplication and to store common logic. Style guides, authentication helpers and API helpers are examples of utility modules.

Conclusion

Micro Frontends are used to increase independence of the team and to ease the overall complexity of the frontend. It provides the same benefits in the same way microservices do with the backend side.  They require careful planning and additional research to find out why and where they are most beneficial.

One of the most popular Micro Frontend frameworks is Single-SPA. Single-SPA brings together all Micro Frontends into one application. Single-SPA enables independent Micro Frontend deployment, it is easy to use and can support multiple frameworks on the same page. If You want to know more about this framework, you can visit https://single-spa.js.org/docs/getting-started-overview.