How to deconstruct a single front-end application--a micro-service split for front-end application

Refreshes the page. Routing split. No, dynamically loading components.

This article is divided into the following four parts: front-end micro-service concept introduction of micro-front-end design concept of actual combat micro-front-end architecture design based on MOOA front-end micro-service front-end tiny

For front-end tiny, there are a number of scenarios: Web Component can clearly be a very good infrastructure. However, it is not possible to duplicate existing applications in large quantities. Iframe. Are you serious? Another micro-front frame Single-spa is clearly a better way. However, it is not Production Ready. By way of segmentation application, and this jump transfer affects the user experience. Wait a minute.

Therefore, when we consider front-end micro-service, we hope: independent deployment of independent development technology without affecting the user experience independent development

Over the past few weeks, I've spent a lot of time learning Single-spa code. However, I found that it was really cumbersome to develop and deploy, and did not fully achieve the standard of independent deployment. By Single-spa's design, I need to make a reputation for my application in the entry file before I can build:

Declarechildapplication (' Inferno ', () => import (' Src/inferno/inferno.app.js '), Pathprefix ('/inferno '));

At the same time, in my application, I also need to specify my life cycle. This means that when I develop a new application, I have to update two code: Master Engineering and application. At this point we are very likely to work in the same source code.

When there are multiple teams, working in the same source code obviously becomes quite unreliable-for example, the team uses TAB, and we use 2 spaces, and the old king next door uses 4 spaces. Standalone Deployment

A single front-end application of the biggest problem is that the build out of JS, css file is quite huge. The micro-front-end means that the file is split into multiple files independently, and they can deploy the application independently. Do we really need technology to have nothing to do with it.

Wait, do we really need technology to have nothing to do with it. The micro-front-end problem is easy to solve if we don't need technology.

In fact, for most companies and teams, technology is nothing but a trivial word. When several founders of a company used Java, it was very likely that Java would continue to be used in future selection. Unless, some extra service to use Python to implement artificial intelligence. Therefore, in most cases, the technology stack is still unique.

This is especially true for front-end projects: one department basically chooses only one frame.

So, we chose the angular. does not affect the user experience

Using route jump to make front-end micro-service is a very simple and efficient way of segmentation. However, in the course of Route jump, there will be a white screen process. In this process, jump before the application and will jump applications, have lost control of the page. If this application is out of the question, then the user will be a face.

Ideally, it should be able to be controlled. The design concept of micro front end design Concept One: Central routing

Is the nature of the internet to be centralized? No, DNS decided it was not. TAB, decided it was not.

Micro-service in essence, it should be to be centralized. However, it cannot be completely centralized. For a micro-service, it requires a service registry :

The service provider will register the notification service address, and the service's caller will be able to discover the target service.

For a front-end application, this thing is routing.

From the page, only if we add a menu link on the page, users can know that a page is available.

And from the code point of view, that is we need to have a place to manage our applications: * * Find out what applications exist, which applications use which routes.

managing our routes is actually managing our applications . Design Concept II: Identification of the application

In designing a micro-front-end framework, the question of naming each project has been a long time to haunt me-how to standardize this thing. Until, once again, I thought of Conway's Law:

System Design (product structure is equivalent to organizational form, the organization of each design system, its design is equivalent to the communication structure between organizations.)

In other words, under the same organization, it is impossible to have two items with the same name.

So, this problem is very simple to solve. design concept Three: life cycle

Single-spa designed a basic lifecycle (although it is not uniformly managed), it contains five states: load, decide which application to load, and bind lifecycle bootstrap, get static resource mount, install application, such as create DOM node unload, Remove Application Lifecycle unmount, uninstall application, such as delete DOM node

So, I basically used this life cycle in design. Obviously, such as load is redundant for my design. Design Concept Four: Independent deployment and Configuration Automation

In a sense, the entire system revolves around the application configuration. If the application configuration can be automated, the entire system is automated.

When we only develop a new component, we just need to update our components and update the configuration. And this configuration itself should be automatically generated. The design of actual combat micro-front-end architecture

Based on the above premise, the workflow of the system is as follows:

The overall engineering process is as follows: When the main project is running, it will go to the server to get the latest application configuration. After the master project gets the configuration, it creates the application and binds the lifecycle to the application. When the main project monitors the routing changes, it will find out if there is a corresponding route matching to the application. When matching is applied to the corresponding application, the corresponding application is loaded.

Therefore, its corresponding architecture is shown in the following illustration:

Standalone deployment and configuration Automation

Our deployment strategy is as follows: Our application uses a configuration file called Apps.json, which is the main project to get this configuration. Each time we deploy, we just need to point the Apps.json to the latest configuration file. The configured file classes are as follows: 96a7907e5488b6bb.json 6ff3bfaaa2cd39ea.json Dcd074685c97ab9b.json

An application's configuration looks like this:

{
  "name": "Help",
  "selector": "Help-root",
  "Basescripturl": "/assets/help",
  "Styles": [
    " Styles.bundle.css "
  ],
  " prefix ":" Help ",
  " scripts ": [
    " Inline.bundle.js ",
    " Polyfills.bundle.js ",
    " Main.bundle.js "
  ]
}

The selector here corresponds to the DOM nodes required for the application, and prefix is used for URL routing. These are automatically obtained from index.html files and Package.json. inter-application routing-event

Because the application now becomes two parts: the main engineering and the application part. There is a problem: only one project can capture routing changes . When the main project to change the application of level two routing, can not effectively communicate to the child application. At this point, the child application can only be notified through the event, and the child application also needs to monitor whether it is the currently applied route.

if (Event.detail.app.name = = appName) {let
  urlprefix = ' app '
  if (urlprefix) {
    URLPrefix = '/${WINDOW.MOOA.O ption.urlprefix}/'
  }
  router.navigate ([Event.detail.url.replace (URLPrefix + appName, ')]
}

Similarly, when we need to jump from application A to application B, we also need such a mechanism:

Window.addeventlistener (' Mooa.routing.navigate ', function (event:customevent) {
  Const OPTS = Event.detail
  if (opts) {
    navigateappbyname (opts)
  }}
)

The rest, such as Loading animations, are similar. use Mooa to

So, we have the front-end micro-service framework MOOA. It is based on Single-spa && SINGLE-SPA-ANGULAR-CLI and conforms to the above design ideas.

Gayhub Address: Https://github.com/phodal/mooa

For the main project, you need only the following lines of code to complete the above functions:

Http.get<any[]> ('/assets/apps.json ')
  . Subscribe (data => {
    data.map (config) => {
      That.mooa.registerApplication (config.name, config, Mooarouter.matchroute (config.prefix));
    This.mooa.start ();
  });

This.router.events.subscribe (Event:any) => {
  if (event instanceof Navigationend) {
    That.mooa.reRouter ( event);
  }
);

and add a corresponding child application route:

{
  path: ' App/:appname/:route ',
  component:homecomponent
}

Then the four steps described above.

For a subproject, only one corresponding Hook operation is required:

Mooaplatform.mount (' help '). Then ((opts) => {
  platformbrowserdynamic (). Bootstrapmodule (Appmodule). Then ( Module) => {
    opts[' Attachunmount '] (module);
  });

and set the corresponding Base_href:

Providers: [
  {provide:app_base_href, useValue:mooaPlatform.appBase ()},
]

Well, it's that simple. DEMO videos are as follows:

Demo address See: http://mooa.phodal.com/

GitHub Example: Https://github.com/phodal/mooa