umi-nest

Realize the application of micro front terminal based on UMI – Nest

Writing in the front

Project code based on UMI – NEST micro front terminal application

Public account “Front-end Thick Say”

QQ group of 713593204

I. Project background

To explore a better scheme according to the actual scene is something we should actively face. So there are bigger and bigger projects. For example, front-end development of TOB, we often run into some difficulties

  • As projects get bigger and bigger, packaging takes longer and longer
  • There are many team members, complex product functions and frequent code conflicts
  • Customers will always demand constant customization
  • Code modification, “pull a launch body”, not easy to maintain
  • The project’s dependency escalation affects the entire application, potentially increasing the risk
  • Become a giant application, lose flexibility, both multi-user collaboration and access costs will greatly increase

With the rise of the micro front end, slowly the industry began to explore it, constantly digging pits. For these or more than just these pain points. We decided to try working in groups. So here’s the problem we need to face

  • The client must be a “one system” experience, from domain name to interactive experience
  • Multiple sub-applications can be split based on service functions, and each sub-application can be independently developed and deployed
  • Sub-app development tries to maintain the same development experience as traditional development and avoid too much learning cost for developers
  • The dashboard can load menus according to permissions and be customized freely. It is supported by a unified communication mechanism between applications, avoiding coupling and low coupling design
  • Compatible with development of different technology stacks (all frameworks are developed by the company)
  • Avoid global shared data contamination between applications

Second, technical research

It is required to achieve the effect that an application contains other sub-applications, “humble” iframes and single-page applications can achieve this purpose.

2.1 the iframe

To avoid impacting each other, a common iframe is used to load each page. The common IFrame is supported by apis provided by the framework design, such as hints, communication, and so on.

There are some problems when using iframe to load:

  • The inner mask cannot mask the outer frame, and the layout is centered
  • Page Indicates the communication between pages
  • Slow page loading (this is acceptable, PC clients load local static resources within 1 second)

2.2 Single-page Application

The original jquery stack was not feasible, with too many potential problems, such as: the same page needs to be displayed in multiple areas, with the superimposition of functions, the efficiency of the selector is greatly reduced, and the mutual influence of styles is inevitable.

2.3 the front end

There have been developers exploring it in the industry, and we focus on qiankun, which is also stepping on the shoulders of giants. So what is a micro front end

2.3.1 History and Concepts

In the first phase of the front end, we still just slice the graph and then wrap the page in the back end. Slowly slowly we begin to separate the front and back ends. The emergence of three frames, also the mainstream framework. You have to photoshop the front end

That was proposed in 2016, which is similar to the concept of microservices.

Techniques, strategies and recipes for building a modern web app with multiple teams that can ship features independently.

We can call microfrontend a solution, or strategy approach technology. We can build unified modern Web applications with different teams and different technologies

2.3.2 Advantages and challenges

Even if we don’t practice the micro front end in our own projects, it will inevitably be mentioned in interviews and other scenarios, just like TypeScript. What’s popular is what people care about. We might want to get an effect like this

  • Service discovery
  • Run the isolation
  • The environment is consistent
  • Ability to incrementally upgrade, update and even rewrite front-end code
    • Large front-end projects are bound to take more than a few years of iteration. We also provide new features to our customers from time to time so that it doesn’t affect the whole thing
  • Independent deployment
    • The independent deployment capability of the micro front end is also critical because it reduces irrelevant risks. No matter where the code is hosted, right
    • We should be able to test deployment and so on without considering other code bases

So given the many advantages, what are the practical problems we will encounter? For example, conflicts such as CSS style isolation of JS code load resources on demand. Some conflicts are conceivable and inevitable. Why? Because a simple project with different developers will inevitably have naming conflicts.

Demand analysis

Now that we have clearly defined our goals, as well as the technical scheme, and envisaged the possible advantages and challenges. We want to analyse the current demand

3.1 Technical Requirements

We chose Reatc with TypeScript for the current stack of popular technologies in the industry

Demand point Margin requirements
Down the decomposition coupling Pages are pages, and components are decoupled (such as popover components)
Learning costs Keep the single-page development experience
Unified technology stack Sub-applications are prohibited from being developed using different technology stacks

3.2 Functions

3.2.1 Background Management

Project to achieve a background admin management background can operate on data

  • Article post: add, delete, change and check the article
  • Users: Add and delete users and modify user information
  • Login registration: Registers login users

3.3 Feasibility of Requirements

As a practical project, we focus on analyzing the technical feasibility of requirements: using web front-end technology, using MySQL database, and TypeORM to design data entities. Technically feasible

3.4 Process Analysis

At the beginning of the design, we need to do a simple analysis of the flow of the sub-application.

3.4.1 Background Management

4. System design

4.1 Technology stack selection

Because the concept of micro front end is directly or indirectly generated by back-end micro services, and ensure that each sub-application can run independently. You need a set of interfaces that can provide services, and a set of front end pages

4.1.1 Back-end selection

The back-end interface selects NestJS, the current NodeJS framework. After investigation, NestJS is a beautiful Node.js framework, considering that using native NodeJS comes with certain costs, including some bug catching monitoring and so on. NEST is a framework for building efficient, scalable NodeJS server-side applications.

advantage
  • The dependency injection container – NestJS comes with its own DiC, a utility that seems to be forgotten in the JavaScript world, but I really can’t live without it. There are some solutions like Inversify or Bottle, but NestJS has its own solution. It also supports factory injection.
  • Modularity – In NestJS, each logical part of an application within the same domain boundary is a module, which encourages encapsulation.
  • Testability – Thanks to the introduction of DiC and Modularisation, you can build applications from services, making the controller’s work easier to test.
  • Use TypeScript – types are fine. You can assign a type to a variable to reduce the likelihood of errors
disadvantages
  • Because it’s based onTSGrammar, high cost to get started
  • Some learning resources are more abroad, domestic resources are relatively less.

4.1.2 Front-end selection

Front-end frameworks and technologies emerge endlessly, and it’s good to learn from the best development practices of others. Domestic Ali in view of the practice of the project generally

  • The syntax (or language) TypeScript
  • Style is less
  • The data flow Dva
  • UI antd

So we are going to use UmiJS, have better data flow management, better combination of TS and ANTD. But in the process of practice will inevitably encounter some pits. But embrace the community

4.1.3 summary

The front end The back-end
Front-end scheme based on UMI ecology Nodejs-based back-end solution

4.2 Architecture Design

4.2.1 System structure design

According to the above requirement analysis, our system is temporarily divided into several modules

  • User registration login module
  • Management module of the article
  • User management module

4.2.1 Functional module design

4.3 Data Table (Data structure)

4.3.1 the users table

4.3.2 article table

5. Business planning

Practice is the only criterion to test truth, and the process of actual development is the process of solving problems. So draw up a development schedule

The date of The front-end progress The backend schedule
2020-06-17 Initialize the front-end project Initialize the back-end project

Six, supplement

6.1 Sub-Application Requirements

  • Child applications need to run independently

  • The child application contains the login page

  • Subapplications contain two modules that require communication before modules

  • Child applications must have forms, tables, pop-ups, and images

    There should be data on the function of the increase, delete, change and check some basic development needs

  • Subapplications include plugins as much as possible

  • The child application needs to communicate with the master application

    For example, the user login status, the primary application login, the child application should automatically login

  • Child applications can communicate with child applications

6.2 Preliminary design drawing

6.2.1 Login and Registration

6.2.2 management page

6.3 Updating records of the plan

  • Draft the planning content of the project for the first time

  • …