Over the past few weeks, there has been a lot of talk about Microfrontend with the release of the Martin Fowler blog post by Cam Jackson on Microfrontend. As a micro front-end “expert”, I also share: how to land the micro front-end.

Microfront-end is a kind of architecture similar to microservices, which applies the concept of microservices to the browser side, that is, the single-page front-end application is transformed from a single single application to a number of small front-end applications into one application. Each front-end application can also be independently developed and deployed. They can also be developed in parallel while sharing components — which can be managed through NPM or Git tags or Git subModules.

Why do you need a micro front end?

The micro front end is not a silver bullet, and it poses as many challenges as microservices.

  • Legacy system migration. Addressing legacy systems is one of the most important reasons people adopt microfront-end solutions
  • Aggregate front-end applications. Microservices architecture that decouples back-end inter-service dependencies. The microfront-end, on the other hand, focuses on converged front-end applications.
  • Lively drive development. New technology, since it is very lively, so learn it.

The realization of micro front end means the split of front end application. The goal of splitting apps is not just to look good architecturally, but also to improve development efficiency.

To this end, the micro front end brings a series of benefits:

  1. Application autonomy. You only need to follow the same interface specification or framework, so that the system is integrated together, there is no dependency between each other.
  2. Single responsibility. Each front-end application can focus only on what it needs to do.
  3. Technology stack irrelevant. You can use Angular while using React and Vue.

In addition, it also has a series of disadvantages:

  • The split base of applications depends on the infrastructure being built, and once a large number of applications depend on the same infrastructure, maintenance becomes a challenge.
  • Smaller granularity means more complex architectures and higher maintenance costs.
  • Once the technology stack is diversified, it means the technology stack is chaotic

After all, there is no silver bullet.

How to design a microfront-end architecture?

Currently, designing a microfront-end application is not an easy task — there are no best practices. In different landing cases, different schemes are used. The main reason for this is that each project faces different situations and uses different technologies. To do this, we need to understand some basic microfront-end patterns.

Architectural patterns

In terms of the relationship between micro-front-end applications, there are two types: base mode (management) and self-organization. They correspond to different architectural patterns:

  • Pedestal mode. Manage other applications through a master application. The design difficulty is small, convenient practice, but the universal degree is low.
  • Self-organizing pattern. Applications are equal and there is no model of mutual management. The design is difficult, not convenient to implement, but the universal degree is high.

For now, the pedestal mode is easy to implement and has a lot of options.

Either way, you need to provide a mechanism for finding applications, called a registry schema for services in the micro front end. Similar to the microservice architecture, either microfront-end approach requires an application registry service, which can be a fixed-value configuration file, such as a JSON file, a dynamically updated configuration, or a dynamic service. It mainly does the following:

  • Apply discovery. Allow the main application to find other applications.
  • Application registration. That is to provide a new micro front-end application, registration to the application registry function.
  • Third party application registration. That is, third-party applications can be plugged into the system.
  • Configure access permissions.

The application can be registered with the registry service at deployment time. If you are managing your application based on a registry, it is easier to develop in pedestal mode.

Design concept

During the practice of micro-front-end, the author found the following points that we need to pay attention to in the design process:

  • Centralization: Apply the registry. The application registry has each application and its corresponding entry. In the front-end domain, the direct representation of the entry can be routing or the corresponding application mapping.
  • Identification application. We need an identifier to identify different applications so that the specified application can be found during installation and uninstallation. A simple model is to name the app according to Conway’s Law.
  • Application life cycle management.
  • High cohesion, low coupling.

The life cycle

The biggest difference between a front-end microarchitecture and a back-end microarchitecture is also here — the life cycle. As a client application, each microfront-end application has its own life cycle:

  • Load determines which application to Load and binds the lifecycle
  • Bootstrap to obtain static resources
  • Mount to install the application, such as creating a DOM node
  • Unload deletes the application life cycle
  • Unmount: Unmounts the application, such as deleting DOM nodes or canceling event binding

This is actually one of the difficulties of the microfront end, figuring out how to load the application in the right way — after all, every front-end framework is different and needs different loading methods. When we decide to support multiple frameworks, we need to go into more detail in this section.

How to break it up?

The next challenge is how to split the application.

Technical way

In technical practice, the micro-front-end architecture can be carried out in the following ways:

  • Route distribution. The reverse proxy function of the HTTP server is used to route requests to corresponding applications.
  • Front-end microservitization. Design communication and loading mechanisms on different frameworks to load corresponding applications on a page.
  • The application. By software engineering, multiple independent applications are combined into a single application in the deployment and construction environment.
  • Micro parts. Develop a new build system that builds part of the business functionality into a separate chunk of code that only needs to be loaded remotely.
  • Front-end containerization. The iFrame is used as a container to accommodate other front-end applications.
  • Application componentization. With the help of Web Components technology, to build cross-framework front-end applications.

There are many ways to implement it, but they are all based on the scenario. In some cases, there may not be an appropriate approach; In some scenarios, you can use more than one solution at a time.

Route distribution

** Routing distribution micro front-end, which distributes different services to different and independent front-end applications through routing. ** This can usually be done through a reverse proxy of the HTTP server, or through the application framework’s own routing. As shown below:

For now, the routing distribution architecture is the most widely adopted and easiest “micro front end” solution. but

Front-end microservitization

** Front-end microservitization is the implementation of microservice architecture at the front end. Each front-end application is completely independent (independent technology stack, development, deployment and construction) and runs independently. Finally, a complete front-end application is combined in a modular way. ** Its architecture is shown in the figure below:

This means that there are two or more front-end applications running on the same page. Routing distribution, on the other hand, has only one application per page.

Composite integration: Microapplication

** Microapplication, that is, at the time of development, applications exist in the form of a single, small application, and at the time of run, these applications are combined into a new application by building a system. ** Its architecture is shown in the figure below:

Microapplication is more in the way of software engineering, to complete the development of front-end applications, so it can also be called combinatorial integration. For a large front-end application, the architecture approach is often to use the business as the main directory, and then put related components in the business directory, and have some common shared templates.

Micro parts,

A widget is a piece of code that can be embedded directly into an application. It is pre-compiled by the developer and does not need to be modified or compiled when loaded. ** While microcomponentization under the micro front end means that each business team writes its own business code and deploits (uploads or places) the compiled code to a designated server. At run time, we only need to load the corresponding business module. Correspondingly, when updating the code, we only need to update the corresponding module. Here is a schematic of the architecture of the microwidget:

In the era of non-unifaceted applications, it is particularly easy to implement a micro-solution. The corresponding JavaScript code is loaded remotely, executed on the browser, and the corresponding component is generated to embed in the corresponding section of the page. Similarly for business components, we write our business components in advance, and then respond and execute when the corresponding components are needed.

Front-end containerization

Front-end container: iframe

Iframe is a very “old” technology that everyone thinks is common, but it has always worked. It can effectively embed another web page/single page application into the current page, and the CSS and JavaScript between the two pages are isolated from each other — except for the iframe parent-child communication part of the code, the code between them is completely independent of each other. Iframe creates a new, separate hosting environment, similar to sandbox isolation, which means front-end applications can run independently of each other.

Build with Web Components

Web Components are a different set of technologies that allow developers to create reusable custom elements whose functionality is encapsulated outside of code and use them in Web applications.

Browser support is the main factor currently plaguing the adoption of Web Components technology. Web Components support is good on Chrome and Opera, but not so good on Safari, IE, and Firefox.

business

As with microservices, it is not easy to demarcate different front-end boundaries. Currently, the following are common ways to divide the microfront end:

  • Split by service.
  • Split by permission.
  • Split by frequency of change.
  • Split by organizational structure. Use Conway’s law to further split the front-end applications.
  • Follow the back-end microservice partitioning. DDD and event storms have proven to be an effective back-end microfront-end split model, and it works well for the front-end as well — directly tracking back-end services.

Each project has its own special context, and the way it shards microfronts is different. Even though the types of projects are similar, there are some subtle differences.

Outside the microfront

If you’re struggling with a micro front end, there are some good architectural patterns to work with.

Apply the micro architecture

Application micro architecture is a front-end architecture pattern of development as a whole, construction as a split, and run as a separate. That is, the application of micro-architecture from a piece of code, to build multiple sets of object code suitable for different environments. In implementation it is a kind of:

  • Split the architecture at build time.
  • Code removal architecture. Laugh, by deleting the code to form each front-end application.
  • Microfront-end readiness architecture. That is, it can be split into multiple front-end applications at any time.

Because of its similarity to microapplication, we contrast it with microapplication. It differs from microapplication in that application microapplication splits the application at build time rather than in local mode. Similarly, it is an application split based on the build system.

That is, microapplication is an architecture that can be merged at any time. Application micro, on the other hand, is a detachable architecture.

It is not only an architectural pattern for the front end, but also an architectural pattern for the back end.

Clean front-end architecture

Clean Architecture is an architectural pattern proposed by Robert C. Martin in 2012. It has some characteristics: framework independence, testability, UI independence, database independence, external agency independence.

For the front-end Architecture, Clean Architecure is actually: Clean Architecture + MVP + componentization. As shown below:

Given the size of the application, here’s an Angular + TypeScript example:

This architectural pattern is particularly suitable for teams that write both the front end and the back end within an organization. It’s easy to map to the front and back apis, and you can use USecase as an anticorrosion layer.

There are no silver bullets. It has to be said that for small teams, it can be more of a disadvantage than a benefit — a lot of redundant code. Although Angular Schematics can generate code from parameters, this layered architecture is too complex for simple applications to get started with. For projects that do not write tests, usecase does not deliver the benefits they promise.

conclusion

The micro front end is not a silver bullet and there are no current best practices, but it is a great learning opportunity.

Excerpt from Front-end Architecture: From Getting Started to Microfrontend