A big but very true cliché in systems architecture is that there is no silver bullet – that is, there is no one-size-fits-all solution for all problems – and micro frontends cannot escape this cliché. The main advantage of this architecture, before any technical aspect, is its organizational aspect.
When we use the micro frontend, we are separating an independent part focused on one aspect of the business that will be handled by a team specializing in that aspect. With this, your project can scale across different teams dealing with specific subjects that will be integrated into an experience for your user. Each team has autonomy in the delivery cycle of this project, with independence from build, deployment, and testing. Independence can reach a level where teams can work with different versions of Angular and even different frameworks such as React and Vue, although this is not highly recommended, as we will discuss in the next section.
When not to use a micro frontend project
Another software engineering cliché is that there is no free lunch, and choosing to use micro frontends has its costs and challenges.
The first challenge is the performance issue of your frontend. As we saw in Chapter 1, Starting Projects the Right Way, in a single-page application (SPA), the user’s browser downloads the application bundle containing the Angular framework code, in addition to the code that your team produced. After this download, the browser interprets the bundle and renders the pages for the user. This entire process must be as quick and efficient as possible because, while it is occurring, the user cannot interact with the screen, causing frustration.
Now imagine this process happening in every part of your system because, to guarantee version and even framework independence, each micro frontend carries its framework engine in the specific version. There are techniques and tools such as webpack’s module federation (https://webpack.js.org/concepts/module-federation/), but you and your team must evaluate this challenge.
Another care we must take is concerning the user experience and the design of the components on screen because, for them, the components between interfaces must be fundamentally the same to guarantee cohesion in their experience.
This challenge can be overcome by implementing a design system – that is, a single design guide for your company’s components, preferably with a library that supports it. An example of a design system is Google’s Material Design.
Now that we have a basic understanding of micro frontends, let’s move on to the next section, where we will explore how to split our application into micro frontends.
Slicing your application into micro frontends
To maximize gains from the micro frontend architecture and minimize the risks defined in the previous section, we need to create microservices that are as independent as possible and that make sense for your team’s organization.
The most common type of project organization is the verticalization of functionalities – that is, for one project you might have an entire user journey, such as a product purchase screen, another project for product registration, and another for the administration module of the application.
Figure 11.1 – Micro frontend division
This diagram exemplifies the concept of division using an Angular application. In each project, we have all the components for the user experience.
You may be wondering, “Can I achieve this same separation using Angular modules?” and the answer is yes, you can. If a team takes care of all the modules for your company’s organization or the teams can organize themselves into just one project, you can (and even should) do this.
We need to keep in mind that the reason for dividing your project into micro frontends is to meet an organizational requirement of your project, and teams want to have deployment and development independence.
With the basic concepts in mind, we will exemplify how to implement them in our gym diary project.
No Responses