Origins of the microfront end

The concept of a microfront-end was first proposed by ThoughtWorks in 2016. Its core idea is to learn from the concept of back-end microservices architecture and split a single huge front-end application into several simple and independent front-end projects. Each front-end project can be independently developed, tested, and deployed. Finally, a container is applied to combine the split micro front-end engineering into a whole and provide services for users.

The benefits of the microfront-end architecture are also obvious:

  • Reduce code coupling
  • The micro front end can be deployed independently
  • Teams can be more efficiently split vertically by business

Common implementations

The micro front end concept has been very popular in the last year or two. But it is important to point out that the micro front end is not a new technology, but a new way of architecture. Community developers give full play to their intelligence and wisdom, providing many ideas to achieve.

iframe

For the front-end students, the easiest thing to think of is iframe. Iframe naturally has the gene for a microfront. We only need to separate the front-end applications of single units according to business modules and deploy them separately. Finally, load dynamically through iframe. A simple implementation is as follows:

< HTML > <head> <title> Micro front end -ifame</title> </head> <body> <h1> I am a container </h1> <iframe ID ="mfeLoader"></iframe>
    <script type="text/javascript">
      const routes = {
        '/': 'https://app.com/index.html'.'/app1': 'https://app1.com/index.html'.'/app2': 'https://app2.com/index.html'}; const iframe = document.querySelector('#mfeLoader');
      iframe.src = routes[window.location.pathname];
    </script>
  </body>
</html>
Copy the code

advantages

  • Implement a simple
  • Natural isolation

disadvantages

  • The maximum number of HTTP links that can be shared by the home page and iframe.
  • Iframe blocks main page loading.
  • The browser’s back button is invalid

Combination of server templates

This approach will be familiar to front-end programmers with a sense of age. A common implementation is for a server to dynamically render a template file for a particular page based on the route. The architecture diagram is as follows:

The container template code looks like this:

<html lang="en" dir="ltr">
  <head>
    <meta charset="utf-8"Micro front - > < title > server-side template < / title > < / head > < body > < h1 > container application < / h1 > <! --# include file="$PAGE.html" -->
  </body>
</html>
Copy the code

Dynamically set the template to load based on the URL path via Nginx server:

server {
    listen 8080;
    server_name localhost;

    root /usr/share/nginx/html;
    index index.html;
    ssi on;

    rewrite ^/$ http://localhost:8080/app redirect;

    location /app {
      set $PAGE 'app';
    }
    location /app1 {
      set $PAGE 'app1';
    }
    location /app2 {
      set $PAGE 'app2';
    }

    error_page 404 /index.html;
}
Copy the code

advantages

  • Implement a simple
  • Technology stack independence

disadvantages

  • Additional Nginx configuration is required
  • Incomplete separation of front and rear ends

Single-spa micro front end framework

For front-end programmers whose motto is “there’s nothing JS can’t do” it was impossible not to build wheels, the famous Single-SPA was created.

With single-SPA, developers can use different technology stacks for different subapps, such as subapp A using VUE and subapp B using React, with no historical debt at all.

The principle of single-SPA is not difficult to implement and can be architecturally divided into two parts: child application and container application.

The difference between subapps and traditional single-page apps is that

  • No HTML entry files are required,
  • The module exported from the js entry file must include bootstrap, mount, and unmount methods.

The container application is responsible for registering the application, activating and mounting the child application when the URL matches the route of the child application, or removing the child application from the page when it is not active. There are two core methods:

  • registerApplicationRegister and download the child app
  • startStart the child application in the active state.

Here’s a simple example of single-SPA:

Container application code

<html>
<body>
    <script src="single-spa-config.js"></script>
</body>
</html>
Copy the code

The single-spa-config.js code is as follows:

import * as singleSpa from 'single-spa';
const appName = 'app1';
const app1Url = 'http://app1.com/app1.js'

singleSpa.registerApplication('app1',() => loadJS(app1Url), location => location.pathname.startsWith('/app1'))

singleSpa.start();
Copy the code

The loadJS method is pseudocode that loads app1.js. Developers need to implement it themselves, or with systemJS.

Sub-application code:

//app1.js
let domEl;
export function bootstrap(props) {
    return Promise
        .resolve()
        .then(() => {
            domEl = document.createElement('div');
            domEl.id = 'app1';
            document.body.appendChild(domEl);
        });
}
export function mount(props) {
    return Promise
        .resolve()
        .then(() => {
            domEl.textContent = 'App 1 is mounted! '
        });
}
export function unmount(props) {
    return Promise
        .resolve()
        .then(() => {
            domEl.textContent = ' '; })}Copy the code

advantages

  • Pure front-end solution
  • Multiple technology stacks are available
  • Perfect ecology

disadvantages

  • High cost of entry
  • Existing applications need to be revamped
  • Cross-application tuning becomes complex

Applicable scenario

There are three common microfront-end architectures described above. The front-end students, who naturally love new things, have long wanted to have a try. So here’s the question. What scenarios are appropriate for a microfront-end architecture? What kind of micro front end is adopted? My view is simple:

  1. Service modules are relatively independent and complex applications
  2. Take into account the technical capabilities of the team and the current business situation to choose the appropriate approach

conclusion

There are three common implementations of the micro front end:

  • Use iframe combinations
  • Server side template rendering combination
  • Single-spa micro front end framework

Next, we will continue to share about the application of micro-front-end in the project, the implementation principle analysis of micro-front-end framework single-SPA and other micro-front-end series content, please pay attention. Welcome to join me on wechat lJH5187 to discuss.

Pay attention to our