directory

  • preface
  • What is a micro front end
  • What can a micro front end do for us
  • Challenges when using a micro front end
  • Micro front-end commonly used technical solutions
  • conclusion

preface

Currently, the single page application development model based on VUE, React, and Angular has become the mainstream of the industry. Benefiting from their rich ecology, we can use these technologies to quickly build a new application that responds quickly to the market. With the continuous development of the company’s business, the application has become bulky and bloated, and gradually becomes a monolithic application that is difficult to maintain. Not to say, it takes a lot of time to build the project every time new requirements are developed and put online, which has a bad impact on the development efficiency and experience of developers. Therefore, splitting a monolith application into multiple sub-applications is imperative.

Typically, we split applications based on the business. Each application has its own warehouse, independent development, independent deployment, independent access, independent maintenance, but also according to the characteristics of the team to choose their own technology stack, greatly improve the efficiency and experience of developers.

App splitting is a great convenience, but it also brings us a new challenge, which is the aggregation of apps. For customers, when they use our products, they want to be presented with a complete application, rather than a scattered number of sub-applications. Therefore, we need to choose a suitable solution that can be compatible with different technology stacks and reassemble the subapplications that have been split.

The micro front is an appropriate solution to help us meet these challenges.

What is a micro front end

The concept of a micro front end, which has long been a cliche, first appeared on ThoughtWorks Technology Radar in 2016, extending the concept of back-end microservices to the front-end world.

Microservices, defined on the wiki, are a software development technology – a variant of the service-oriented Architecture (SOA) architectural style that constructs applications as a set of loosely coupled services organized by lightweight communication protocols. Specifically, a single application is broken down into a set of services according to certain rules. These services, each with its own repository, can be developed independently, deployed independently, have separate borders, managed by different teams, and even written in different programming languages. But for the front end, it’s still a complete service.

Microservices are designed to address the limitations of change and extension caused by a large block of back-end services.

Similarly, in the face of increasingly heavy front-end applications, the idea of micro-services can be copied to the front-end, and there is the concept of micro-front-end. Just like microservices, a front-end application can be divided into different sub-applications according to certain rules, independently developed and deployed, and then aggregated into a complete application facing customers.

Micro front-endThe general structure of:

The figure above is taken from what the micro front is.

What can the micro front bring us

  • A simple, decoupled, loosely coupled code repository

    Compared with Stonehenge using a whole block of code warehouse, the code warehouse under the micro front-end architecture is more simple and lightweight. The code of each warehouse can be split based on business, permission, change frequency, organizational structure, back-end microservices and other principles. The boundary is clear, coupling is reduced, and it is convenient for developers to quickly locate source code in the development process, improve development efficiency and reduce maintenance costs.

  • Independent development, independent deployment

    With the code base split, we can develop independently from each code repository. Due to the smaller code volume, the project construction time is shorter, which greatly improves the development efficiency.

    In addition, each project has its own delivery pipeline (build, test and go live) and can be deployed independently, with no consideration for other projects.

  • Technology stack independence

    In a real project, different projects will use different technology stacks for a variety of reasons. Development frameworks such as React, Vue, Angular, etc., and build tools such as WebPack, Rollup, Parcel, etc., can be inconsistent. With a micro front-end architecture, it is possible to aggregate sub-applications using different technology stacks (different versions)

  • Legacy System migration

    In every company, there are some applications that use older stacks, such as Backbone, Vue1.0, Angular2, jquery, etc. The apps are already online and have no new features. There’s no reason to waste time and effort on an application like this, which can be directly integrated into the new application with a micro front end solution.

    A big part of the reason for using a micro front end solution is to address legacy migration issues.

  • Technology stack upgrade

    In addition to legacy migration, the micro front end can also help with technology stack version upgrades.

    Some of the projects, when they were founded, used the latest technology such as ANTD2. With the development of technology, ANTD has been updated to 4, but since the project has been iterated, antD2 is still used. Direct complete refactoring, certainly is not realistic, time-consuming and laborious not to say, the risk is also large.

    In this case, we can restart an application, gradually refactor the application using ANTD4, and then use a micro front end solution to bring the old and new applications together.

  • Team technical growth

    The advantage of microfront-end technology stack independence can give the team more opportunities to try out new technologies (vuE3, Webpack5, etc.) in the project, which can help the whole team grow in technology.

Challenges when using a micro front end

While the micro front-end solution brings us great convenience, it also brings us new challenges. When implementing micro front-end applications, we must consider the following questions:

  • Subapplication switching;
  • Applications should be isolated from each other and not interfere with each other;
  • Communication between sub-applications;
  • Multiple sub-applications coexist;
  • Storage-free user state;

Micro front-end commonly used technical solutions

At present, the mainstream micro front end implementation solutions in the industry mainly include:

  • Routing distribution is a front-end
  • iframe
  • single-spa
  • qiankun
  • Webpack5: module federation
  • Web Component

Routing distribution is a front-end

Routing distribution indicates that different services are distributed to different independent front-end applications through routes. The most common solution is a reverse proxy for an HTTP service.

Here is an Nginx configuration based on routing distribution:

http { server { listen 80; server_name xxx.xxx.com; location /api/ { proxy_pass http://localhost:3001/api; } location /web/admin { proxy_pass http://localhost:3002/api; } location / { proxy_pass /; }}}Copy the code

With this configuration, requests for different pages can be distributed to different servers.

Advantages:

  • Simple implementation;
  • No modifications to existing applications are required;
  • Completely stack independent;

Disadvantages:

  • The user experience is poor, the browser has to reload the page every time you switch apps;
  • Multiple sub-applications cannot coexist;
  • The limitation is relatively large;
  • Communication between sub-applications is difficult;
  • You need to log in again when switching over sub-applications.

iframe

As a very old technology, iframe can also be used to implement a micro front end. With iframe, you can easily embed one application into another, and the CSS and javascript between the two applications are isolated, so they don’t interfere with each other.

Advantages:

  • Simple implementation;
  • CSS and JS natural isolation, mutual interference;
  • Completely stack independent;
  • Multiple sub-applications can coexist;
  • No modifications to existing applications are required;

Disadvantages:

  • The user experience is poor because the browser has to reload the page every time you switch apps.
  • UI is not synchronized, DOM structure is not shared;
  • The global context is completely isolated, memory variables are not shared, and communication and data synchronization between sub-applications are complicated.
  • Not SEO friendly;
  • When switching sub-applications, you may need to log in again, which leads to poor experience.

single-spa

The routing and forwarding mode and iframe mode, although they can achieve a micro front end, have a bad experience. Each time we switch back to a child application that we have already accessed, we need to reload the child application, which has a significant impact on performance.

As we know, the dominant model for front-end app development is the vue/React/Angular single-page app development model. In this mode, we need to maintain a routing registry, with each route corresponding to its own page component URL. If the route is a new page, you need to dynamically obtain the JS script corresponding to the route, and then execute the script to render the corresponding page. If it is a page that has already been visited, then get the cached page method directly from the cache, execute and render the corresponding page.

Is there a similar implementation solution for a micro front end to achieve the same user experience as a single page application?

The answer is yes. Single-spa offers a new technical solution that can help us achieve an experience similar to a single page application.

In single-SPA solutions, applications are divided into two categories: base applications and sub-applications. Among them, sub-applications are the sub-applications described above that need to be aggregated; The base application is a separate application for the aggregator application.

Similar to the implementation of single-page applications, single-SPA maintains a routing registry in the base application, with one child for each route. After the base application is started, when we switch routes, if it is a new subapplication, we will dynamically obtain the js script of the subapplication, and then execute the script and render the corresponding page. If it is an already accessed subapplication, the cached subapplication is retrieved from the cache, activated, and rendered.

Here, this article is only a preliminary introduction to single-SPA, if you need to in-depth understanding, see the official website: Single-SPA and micro front-end learning series (2) : Single-SPA.

Advantages:

  • When switching between apps, the browser does not reload the page, providing the same user experience as a single-page app.
  • Completely stack independent;
  • Multiple sub-applications can coexist;
  • Rich ecology;

Disadvantages:

  • The original application needs to be modified, and the application should be compatible with SING-SPA and independent use.
  • There are additional learning costs;
  • The use of complex, about the child application loading, application isolation, child application communication and other problems, need to implement the framework users;
  • The same resource is repeatedly loaded between sub-applications.
  • To start an application, start the base application first;

qiankun

Like single-Spa, Qiankun can provide a user experience similar to a single page app. Qiankun is a secondary development on the basis of single-SPA, in the framework level to solve the use of single-SPA requires developers to write their own sub-application loading, communication, isolation and other logic problems, is a better than single-SPA micro front-end solution.

Here, this article also only makes a simple explanation of Qiankun, for in-depth understanding, see the website: Qiankun and micro front-end Learning series (3) : Qiankun.

Advantages:

  • When switching between apps, the browser does not reload the page, providing the same user experience as a single-page app.
  • Compared with single-SPA, it solves problems such as sub-application loading, application isolation and sub-application communication, and is relatively simple to use.
  • It’s completely stack independent;
  • Multiple sub-applications can coexist;

Disadvantages:

  • Need to transform the original application, the application should be compatible with Access to Qiankun and independent use;
  • There are additional learning costs;
  • Loading the same resource repeatedly;
  • To start an application, start the base application first;

Webpack5: module federation

The new release of webpack5 provides a new feature – module federation. With this feature, we can dynamically load and run code from one javascript application and share dependencies between applications.

Module federation allows you to dynamically render pages from one application to another, thus enabling the aggregation of multiple sub-applications.

The usage of Module federation is detailed in the micro front-end learning series (4): Module Federation.

Advantages:

  • No need to change the original application, only need to change the package script;
  • When switching between apps, the browser does not reload the page, providing the same user experience as a single-page app.
  • Multiple sub-applications can coexist;
  • The same resource does not need to be loaded repeatedly.
  • Development technology stack independent;
  • After the application is started, no resources irrelevant to the application need to be loaded.
  • Don’t enter friendly;

Disadvantages:

  • The build tool can only use WebPack5;
  • There are additional learning costs;
  • Not friendly to old projects and needs to revamp WebPack;

Web Component

Based on the Shadow Dom capabilities of the Web Component, we can also implement a micro front end that aggregates multiple child applications together.

The Shadow Dom is used as follows:

const shadow = document.querySelector('#hostElement').attachShadow({mode: 'open'}); Fetch (url).then(res => {shadow.innerhtml = res});Copy the code

Advantages:

  • Simple implementation;
  • CSS and JS natural isolation, mutual interference;
  • Completely stack independent;
  • Multiple sub-applications can coexist;
  • No modifications to existing applications are required;

Disadvantages:

  • The main problem is browser compatibility;
  • High development cost;

conclusion

This concludes the introduction to the micro front end. This article is the beginning of the micro front learning series, after we will continue to launch micro front learning series: single-SPA, micro front learning series: Qiankun, Module Federation, I hope that through the study of these articles, can let you have a more profound understanding of the micro front, 😁.

References for this article:

  • Front-end architecture: from entry to micro front-end
  • What exactly is a micro front
  • Micro front-end
  • Micro Frontends
  • I don’t understand micro-frontends
  • single-spa
  • qiankun