First published in the Language finch documentation

Here’s the background

Instead of using a Resful style API, our backend project uses a backend gateway, which distributes requests. Here’s how:

  • Request all posts
  • The request URL is/AGRS
  • The data submission mode is Application/JSON
  • Data formats can be roughly divided into:
    • System 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 changes as the case may be
  • File transfer through OSS, not through form file stream
  • .

Pain points

The front-end can’t wait until the back-end is finished to write the code, so we need mock. However, the gateway request distribution makes mock development very inconvenient because of the above requirements.

  1. To create a mock in the traditional way, you would request one set of URLS for development and change them all to/AGRS for packaging.

I want it to be the same at development time and packaging time, without having to change two sets of standards

  1. When you need a new mock, according to umi’s Mock specification, you need to create a JS file in the mock folder and expose an object by default, such as:

mock/getApps.js

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

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

Our project is umi. See mock data for details

  1. As per point 2, when the back-end interface service name & interface name is actually provided, we need to change the mock file name as well as the URL name of the exposed object in the mock file for consistency.
  2. The mock file name must be the same as the URL that the mock intercepts, otherwise it will be a pain to look at many interfaces.
  3. Mocks that intercept the same URL can be overwritten in the way that JS exposes modules. People who do not know will be confused when the URL of the mock is correct but the response data does not match
  4. .

The above inconvenient, is not imaginary, because it is to pay time, manpower, come to this conclusion is really inconvenient, light above the first point, it has been enough.

To solve

The general idea is: only intercept the URL/AGRS, use Node.js to obtain 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. Solutions to the above pain points:

  1. Development and packaging are the same, using the same URL: / AGRS.
  2. Instead of using JS to expose modules, use JSON files that place jSON-formatted mock data of interest, while other repetitive 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. (Point 2 mentioned no more definition and exposure, so if the change is not as troublesome as before, just change the directory name and file name.)
  4. In any system, folders or files with the same name cannot appear in the same directory. The directory specification in point 3 can solve the problem of repeated overwriting and can also duplicate other people’s existing interfaces.





Code is not complex, self-perception is more important, regardless of the size of the problem, will think how to solve the better, continue to sum up, continue to accumulate it.

Github

Github.com/blueju/mock…