Starting from
Language finches document

The background is this

Our company’s back management project uses not a RESTful style API, but a back management gateway, which will distribute the request. The details of how to distribute the request are as follows:

  • Request all go POST
  • The request URL is unified to /agrs
  • The data is submitted by application/json

  • Data formats can be roughly divided into:

    • System Message Header

      • The service name
      • The interface name
      • Interface version number
      • System identification

    • Local header

      • The user information
      • The paging information
      • Equipment information

    • The style

      • Dynamic data that varies as the case may be
  • File transfer using OSS, not form file stream
  • .

Pain points

We can’t wait for the back end to be developed before we start writing code, so we need to mock. However, the gateway request distribution makes mock development very inconvenient due to the above requirements, including:

  1. I mock up the URL in the traditional way, and then I use /agrs for all URLs, and then I use /agrs for all URLs.

What I want is for development and packaging to be the same, without having to change two sets of standards

  1. When a new mock is needed, following the UMI Mock specification, a JS file is created in the Mock folder and an object is exposed by default, such as:

mock/getApps.js 

export default {
    "POST /getApps": {
      sysHead: {},
    localHead: {},
    body: {},
  }
}

I need to write duplicate code and duplicate data structures many times (sysHead, localHead), and I just want to focus on the mock data in the body

Our project is umi. See mock section for more details
The Mock data

  1. As mentioned in point 2, when the service name & interface name of the backend interface is actually provided, in order to be consistent, we need to change the URL name of the exposed object in the mock file as well as the mock file name.
  2. If the name of the mock is the same as the URL that the mock intercepts, it will be difficult to read all the interfaces.
  3. A mock that intercepts the same URL can be overwritten without knowing it. If the URL of the mock is correct, the response data will not be the same, and the URL will not be the same
  4. .

The above inconvenience is not a figment of the imagination, because it is to pay time, manpower, drawn really inconvenient this conclusion, the light is above the first point, has been enough.

To solve

The general idea is to intercept only the URL /agrs, use Node.js to get the parameter service name and interface name in the request message request, join the path according to the designed directory structure, read the file according to the path, format it with JSON, and finally return it. Corresponding measures to the above pain points:

  1. At development time and packaging time, the same URL is used: /agrs.
  2. Instead of using JS to expose the module, you use JSON files directly, where you place the JSON mock data that you focus on, and other duplicate data structures are consolidated elsewhere.
  3. The directory specification is designed so that the directory name is the service name and the mock file name is the interface name. (As mentioned in point 2, there is no need to redefine and expose, so if the changes are not as cumbersome as before, just change the directory name and file name.)
  4. In any system, the same directory is not the same folder or file of the same name, according to the third point of the directory specification can solve the problem of repeated coverage, but also repeat the existing interface of others.

Not everyone will encounter this situation. It’s just a small tool library to help the internal front end team improve the development experience. It’s also what you should do as a front end team leader.

Code is not complex, I feel more important is that, no matter the size of the problem, will go to think how to solve the better, continue to summarize, continue to accumulate it.

Github

https://github.com/blueju/mock-request-distribute