It is said that the world trend, long separation will be united, and long separation will be divided. At the weekend, the seven states were divided and merged into Qin. And after the end of the Qin Dynasty, chu and Han were divided and merged with Han. The Han Dynasty was divided into three kingdoms after Emperor Gaozu cut off the white snake and rose up to rule the whole country.

It can be said that the history of Internet project development is a history of continuous separation. The following is the background project development evolution process:

  • The whole program is written in one file. It’s too big. Okay, so break it up into modules.
  • Modules are too cluttered to stack in one directory, so let’s split it up into layers.
  • As a project gets bigger and bigger, it’s hard to package, it’s hard to find, ok, let’s split it up, let’s do microservices

The back end has always been dominant. After so many years of evolution, the back-end project development process has become very mature. The front end becomes an important factor affecting the development efficiency, how to do, it is divided, front and back end separation. So the front end starts to develop. The evolution history of the front end in the past ten years also follows the footsteps of the back end, which is divided into modules and layered, and the rise of the micro front end in 2020.

Here are a few important timelines:

  1. In August 2006, jquery1.0 was released. (IIFE modular)
  2. In 2009, angular1.0 was released. (MVC front-end framework)
  3. In 2009, Node.js1.0 was released. (CommonJS Modular Standard)
  4. In May 2011, NPM1.0 was released. (The front end also has maven dependency management similar to the back end)
  5. Webpack was born on March 10, 2012. (The cornerstone of the modern front end)
  6. In May 2013, Act1.0 was released. (Data-driven, componentized)
  7. In January 2014, vue1.0 was released. (Data-driven, componentized)
  8. In June 2015, es6 was released. (Direct browser support for modularity)
  9. Webpack released version 5.0 on October 10, 2020. (Front-end microservice support)

The world is divided into three parts. Separation also brings its own set of problems.

This paper mainly discusses the front-end deployment and development of micro-service + micro-front-end mode.

The so-called micro front end is to divide a large front end project into projects, which are completed by different teams or individuals. Make up a large application. I’ve divided it into two modes, just in my opinion, one is page composition and one is route composition. This paper mainly introduces the front-end deployment and development of the route combination micro front-end project.

Speaking of front-end deployment and development, most of the front ends have dealt with Nginx and Webpack-dev-Server, so I’ll start by talking about the two tools, or proxy tools, that are most closely related to deployment and development.

webpack-dev-server

Webpack-dev-server is a proxy server written by JS and running in the Node.js host environment.

Proxying certain urls can be useful when you have separate API back-end development servers and want to send API requests on the same domain.

Micro is the typical service, interface address port and front-end static file service port address inconsistencies, which leads to cross domain, but in fact, we are allowed to this address the front end of the page to invoke the service (the same-origin policy is mainly for the sake of safety, the service of an enterprise will not be other programs are not allowed to call, this is very important, or leakage of trade secrets).

The ones we use most are its static file service and proxy service. These are the following two configurations:

const path = require('path');

module.exports = {
  / /...
  devServer: {
    static: {
      directory: path.join(__dirname, 'public'),},// Set the static path to public, that's why index.html is always in the public folder, which is the entry point for single-page applications.
    port: 9000.// Configure the front-end startup port. If the port is occupied, the port number will be +1
    proxy: {
      '/api': {
        target: 'http://127.0.0.1:3000'.pathRewrite: { '^/api': ' '}},// This proxy configuration takes effect as long as the address requested by our interface has the API path.}};Copy the code

When we are in the local development, for example, page requests a site http://localhost:81/api/micro/staticFile, so our agent if you have the above configuration, the agreement request address domain name port will be changed to target, And through the regular pathRewrite to match the API replacement is empty, so the actual request address will be http://127.0.0.1:3000/micro/staticFile, because the webpack dev – is also a client server, The client does not encapsulate cross-domain requests and passes the requested data to the front end.

nginx

Nginx is a high-performance HTTP and reverse proxy Web server

Oh, why does Encyclopedia say that?

Why is it HTTP

HTTP is a protocol for retrieving web resources such as HTML. It is the basis for data exchange on the Web and is a client-server protocol, meaning that requests are usually initiated by a recipient such as a browser. A complete Web document is usually a patchwork of different sub-documents, such as text, layout descriptions, images, videos, scripts, and so on. From (MDN)

That is, Nginx uses the HTTP application layer protocol to receive, process and send various Web resources, such as text, layout descriptions, images, videos, scripts, and so on.

Why a reverse proxy Web server

The reverse proxy server is located between the user and the target server. However, for users, the reverse proxy server is the target server. Users can access the reverse proxy server directly to obtain the resources of the target server. At the same time, users do not need to know the address of the target server, nor do they need to make any Settings on the client side. A reverse proxy server is usually used for Web acceleration. That is, a reverse proxy is used as the front of the Web server to reduce the load on the network and server and improve access efficiency. (From Baidu Baike)

Normally, the browser proxies the user’s requests. In development, webpack-dev-server proxies the server’s requests, making requests to the back end. This is called forward proxies. That is, the behavior of the initiator of the proxy request.

The function of nginx here is to proxy the data that the back-end service responds to the client, rather than the back-end directly returns the data to the front-end, so it is called a reverse proxy. Using reverse proxy, we can do load balancing of distributed servers.

We will use nginx’s reverse proxy service for front-end deployment. For front-end development, we will use the forward proxy service of Webpack-dev-server. Well, that’s all for the background. Open dry.

This paper is divided into three parts.

  1. How do we deal with urls
  2. How do we deal with cross-domains
  3. How do we approach the development environment

How do we deal with urls

URL stands for Uniform Resource Locator

A URL consists of protocol, domain, port, path, parameter, and segment.

  • Protocol, domain name, and port can locate a server process on a host
  • Path Locate resources on the network server. In the early days of the Web, paths like this represented the location of physical files on the Web server. Today, it’s mostly an abstraction handled by a Web server without any physical reality.
  • Parameters are additional parameters provided to the web server
  • The fragment identifier is never sent to the server.

The meaning of relative paths (urls) in various front-end cases

  • For HTML documents, the relative path is relative to the path of the HTML document.
  • For CSS, the path relative to the CSS document.
  • / is the delimiter. If a path starts with a slash (/), the path is an absolute path with the domain name protocol and port prefix.

So our front-end address is roughly divided into interface address, as well as STATIC resources such as HTML, CSS,font and JS.

Static resource deployment, address rules

Static resources We are deployed on an Nginx reverse proxy server. Nginx can configure different ports to point to different base directories to serve as static resources. Here we upload a static file to can be any directory on the server, and then nginx configuration a port associated with the specified directory, so that when we pack the static file directory on the server address written on the page, you can access when access to the corresponding static resources, if you have questions, please let us have your specific learning nginx. For example, we put the packaged files in a directory, such as the MyWebApp directory. So when we use Webpack, we just need to set publicPath to/myWebApp /. Other more detailed paths will be handled correctly by Webpack for us. This packaged code will be able to switch page port IP as the Nginx code is configured without repackaging the front-end code, which is relative to the protocol domain IP port.

Rules for interface addresses

Because the back end becomes a microservice, and the front and back ends are separated, if you put the front and back code together again, it’s not called front and back end separation. However, due to inconsistent ports, the front-end address will be written as a relative address and the port will fail. The IP and port you access are not my back-end, so there is no service at all. At this point, you can leverage nginx’s reverse proxy service. Provides interface services for the front end through Nginx. The core of proxy configuration, then, is to provide specific prefixes for the nginx reverse proxy server to recognize.

Therefore, we need to follow certain conventions when we write interfaces, that is, each interface address is concatenated, that is, concatenated like this:

const BASE_URL = '/api'
`${BASE_URL}/micro/staticFile`
Copy the code

It is recommended to put BASE_URL in a public JS so that we can dynamically change the proxy prefix.

How do we deal with cross-domains

The solution is to have multiple servers serving different requests, sort of like load balancing, but not all milk is called Terunsus. The specific configuration is as follows: when the front-end requests the interface address, nginx configures the port service, but actually the interface service is provided by the back-end port, because of the proxy, there is no cross-domain problem. The proxy pseudo-configuration is as follows, thanks for the support of the backend students:

port 200
proxy { api: 127.0. 01.:500}
Copy the code

Port 200 is the front-end static resource service, and port 500 is the actual back-end service. When port 200 receives an API request at the address, it proxies to the 500 back-end interface. In fact, the public IP address and internal IP address of the same computer are different, but the port service and process are the same. After static resources and interfaces use relative addresses, no matter which server the front-end deployment is on, my mother no longer needs to worry about my IP is wrong.

How do we approach the development environment

The interface address is easily handled by proxy configuration using Webpack-dev-server. So what about static resources. In fact, it is implemented by configuring proxy. For example, static addresses starting with gateway are proxy to an existing service, that is, configuring proxy.

 '/gateway': {
        target: 'http://127.0.0.1:3000',},Copy the code

As a micro front end of the routing combination pattern, its dynamic subsystem resources are returned by the server, and its resource addresses are handled by the framework, which does not need to be worried about.

Thank you for reading. The front-end deployment and development under micro-service + micro-front-end mode is introduced here. Our core is to understand the relative address, proxy configuration of Webpack-Dev-server and Nginx reverse proxy configuration, and other address configuration is handled by the micro-front-end framework.