Invention patent disclosure--an Api Mock/proxy tool that supports multi-project, multi-branch and multi-person collaboration based on JSON file + Http Header

At the present stage, under the mainstream development mode of front-end and back-end separation: the front-end and back-end adopt parallel development methods, and the front-end development process usually needs to be attached to the commonly agreed interface format and data.

This process is a parallel process, so the return of the Api Mock simulation interface becomes necessary. At the same time, during the joint debugging process, it is also necessary to modify the back-end service address for joint debugging.

The team's solution is now announced, which is also part of the team's 21-year patent (patent publication number: CN113630468A).

Historical status

During front-end development, two services need to be started locally, one is used to support web static resources, and the other is used to simulate the background API interface.

Among them, the static resource service includes a proxy API address function, which is used to forward the background data interface sent by the browser (general interface prefixes have the same characteristics, for example, they all start with "api/") and forward them to the background On the service of the API interface. Then there are roughly three usage scenarios:

1. When developing the front-end page, the proxy will be set to the local service that simulates the background API interface (the development environment address in the figure below: http://localhost:8080)
2. When joint debugging with the background interface, the proxy will be set to the background API interface service (the background environment address in the figure below: http://192.168.0.100:8080)
3. In the testing phase, the front-end troubleshooting problem is that the proxy may be set to the API interface service of the test environment (the address of the test environment in the figure below: http://192.168.0.200:8080)
   

Brings up problems:

1. The joint debugging may be one-to-many (one front-end developer conducts joint debugging with multiple back-end developers), and multiple back-end developers mean that there are addresses of multiple back-end environments. Then after the joint debugging with "Background A" is completed, the agent needs to be switched to "Background B". Such a rotation may also be cross-jointed with "Background A" and "Background B". In this way, in the current front-end project mechanism, the steps to change the proxy address are:

   Step 1: Modify the ip address in the configuration file
   Step 2: Kill the front-end service
   Step 3: Restart the front-end service (this process will execute the compilation process of the front-end static resources, and the startup speed will vary depending on the size of the project)

   In short, in order to change the proxy address, a lot of irrelevant things need to be done, which affects the efficiency of development and joint debugging.

2. A front-end developer is often interspersed in multiple front-end projects. For example, in the following scenarios:
   
   multiple projects are running in parallel, which may cause the problem of proxy address port conflicts, which also requires frequent modification of the proxy address, and then restarting the front-end project .

Implementation ideas

Realize the goal : modify the proxy address without recompiling the entire front-end project!
Implementation method : extract the unified proxy service fusion-mock, and unify the proxy address in the front-end project as the address of fusion-mock; configure the forwarding strategy of the target address in fusion-mock!

Develop a unified proxy platform, and all project proxy target addresses are on this platform. The platform identifies different projects and different developers by identifying the corresponding logo, and then forwards and processes according to the obtained information, so as to achieve unified management without modifying the target address every time (avoiding repeated construction).

1. The Mock data storage method is improved from "DB" to "JSON file"
   using JSON file storage (each interface corresponds to a JSON file), without the need to build an independent DB service. The management of related JSON files is simple, and can be hosted along with the project in related code warehouses such as Git.

   • Easy to create: such as: /api/users/person/jerry=> Create under /users/personthe directory jerry.json, the relationship is clear and easy to understand!
   • Convenient management: Mock data is stored in the current project and managed as a resource file with the project source code. Cooperating with the development process, Mock data can be well isolated and reused.
   • No need to deploy: no independent Mock service (including DB service, etc.)
     

2. Use the Http Header to identify relevant information and unify the proxy address

   const mockPath = join(__dirname, 'mock')
   
   devServer: {
         
         
     host: '0.0.0.0',
     proxy: {
         
         
       '/api': {
         
         
         // fusion-mock地址
         target: 'http://localhost:18080',
         /*
         * 'mock-server': '项目标识',
         * 'mock-path':'mockdata路径'
         */
         headers: {
         
          'mock-server': 'am-fe', 'mock-path': mockPath },
         changeOrigin: true
       },
       '^/websocket': {
         
         
         target: 'ws://localhost:18080',
         headers: {
         
          'mock-server': 'am-fe' },
         changeOrigin: true,
         ws: true
       }
     }
   }
   

   All developers can uniformly configure the service address of Fusion Mock (such as: http://domain:port); different projects are associated through the fields in headers. Switching the connection address does not need to be rebuilt, it only needs to be dynamically modified on the tool.
   

3. The same project, multi-person collaboration mode
   For the online collaborative development of the same project, multiple developers need to connect to different target servers, and Http Referer can be identified to identify different developers and perform differential forwarding.
   ​Referer: http://localhost:8080/api/auth/time?xxx
   

specific implementation

1. The mock mechanism needs to be implemented in the project directory to match the API path and the storage JSON file path. The last level in the API path is the JSON file name, and the previous level is the folder directory. For example: /users/person/jerrythe corresponding JSON file is: project path/mocks/users/person/jerry.json

   mocks/server.js

   app.use(async ctx => {
         
         
     let url = ctx.request.url
     // /api/users/person/jerry => /mocks/users/person/jerry.json
     let filePath = path.join(__dirname, ctx.request.path.replace('/api/', '') + '.json')
     let data
     if (fs.existsSync(filePath)) {
         
         
       try {
         
         
         data = jsonfile.readFileSync(filePath)
       } catch (err) {
         
         
         console.error('request: ' + url + ' fail!!!')
       }
     } else {
         
         
       console.warn('request: ' + url + ' not exist!!!!')
     }
     ctx.set('Content-Type', 'application/json')
     ctx.body = data
   })
   

2. Realize an integrated proxy tool, all front-end projects will forward requests to this tool address, and the tool will be distributed uniformly (secondary forwarding is performed according to the set address). The details are as follows:

   • The front end reflects its own logo in the Header (reflecting in the Header is not intrusive to the project)

     proxy: {
             
             
     	'/api': {
             
             
       	// fusion-mock地址
     		target: 'http://localhost:18080',
      		/*
       	 * 'mock-server': '项目标识',
       	 * 'mock-path':'mockdata路径'
       	 */
       	headers: {
             
              'mock-server': 'am-fe', 'mock-path': path.join(__dirname, 'mock') },
     		changeOrigin: true
       }
     }
     

   • The integrated proxy tool identifies the identity in the Header, and performs related proxy settings and reading according to the identity

   • The integrated proxy tool can perform matching proxy forwarding according to the keywords in the referer

   • When the integrated proxy tool reads that no proxy is set for the project, it uses the absolute mock path carried in the header by default to read the JSON file in the project.

      // mockServer 应该是被代理项目的名称，也是mock-assets中的文件夹名称
      const mockServer = ctx.header['mock-server'] as string
      const mockPath = ctx.header['mock-path'] as string
      
      // 如果匹配到了 referer 的配置或者开启了 proxy
      if (isMatcheMReferer || isttpRemoteProxy) {
             
             
        // 转发到目标 url
        await await proxyBranch(ctx, targetUrl)
        // return 结束函数运行
        return
      }
      
      // 拆解path路径 找到对应的文件，ctx.mockpath 为 mock 地址的绝对路径
      const filePath = join(_mockPath, ctx.path.replace(searchValue, '') + '.json')
      // read. 读取文件内容
      const content = await promises.readFile(filePath, 'utf8')
      ctx.body = JSON.parse(content)
      ```
     

Summarize

1. The storage form where the JSON file path matches the API path (simple and efficient);
2. Rely on Http Header to identify identity and perform dynamic proxy;
3. Relying on the multi-person collaboration mode implemented by the Http Referer custom agent.

How to separate the "variables" is the core of solving the above problems, and then use the transmission process to transfer the "variables" and unify the logical processing.