Why are you suffering more from frontend and backend separation?

?

Have you ever met:

• The front-end code has just been written, and the back-end interface has changed.

• The interface document is always incorrect.

• The test will always be available soon.

Why are you suffering more from frontend and backend separation?

The frontend and backend separation is no longer news, and more problems are encountered after the real separation. To solve the current pain, you must know the cause of the pain:

Why does the interface change frequently?

I didn't think about it at the beginning of the design. This requires improved understanding and interface design capabilities.

The cost of changes is low.

There is a saying in Germany: "spit in the soup ." Only in this way can people give up the bowl of soup and stop unreasonable behavior. When the frontend and backend students work together, the efficiency will be improved. When the backend students' interface changes, you only need to verbally inform us. We have no documentation, so we are very agile. Yes, we need to acknowledge that this cooperation with development is very efficient, but frequent changes will lead to constant rework, resulting in another waste, which can be reduced, or even eliminated.

Why is the interface document always wrong?

The interface documentation plays a certain role in interface determination, so it is useless to write the interface. As the subsequent interfaces change frequently, the document will always lag behind the actual interface, and the maintenance of the document will bring a certain cost but will not bring value. Who can refer to this document unless it provides external interfaces? No one looks at it. Where is it useful?

Some companies simply drop the interface documentation and say we need to embrace agility.

The reason why the interface documentation lags behind is that it does not bring us value.

Why can't the test work be started until it is launched soon?

One requirement is four days for backend development, four days for front-end development, and four days for joint debugging. Only two or even fewer days are left for testing students, and bugs can only be put online after testing.

 

 

In the development phase, testers cannot intervene, interfaces are changing, and the front-end is also changing. before the test, they can only drink tea. After the test, they are very busy.

 

Automation? Don't even think about it. You can only test it manually after "embracing changes. Occasionally, you need to pull the front-end girl to test the girl. Manual testing is boring, and tedious work is prone to errors, and it cannot be repeated quickly, so it is impossible to quickly return to tested functions.

How can this problem be solved?

To solve the above problems, we need to make the interface documentation take full advantage of the value, increase the cost of the changed interface, and test early intervention.

 

The interface document must assign the bid value to the contract, just as no one is allowed to change the signature, so that we can only recognize the contract and not recognize people.

 

The contract should be driven by the front-end personnel and negotiate with the front-end. As front-end students are closely connected with UX, they have a better understanding of the data required for the page and the overall user journey, and the front-end drivers will be more reasonable.

 

After the contract is finalized, we need to help us generate the mock server (a tool will be introduced later). The front-end and back-end students should develop according to the contract. The mock server can temporarily replace the background service to help the front-end development of the Group. At the same time, testers can also write test scripts according to the contract documents and use the mock server for script verification.

 

 

When the backend interface changes, the contract must be modified in addition to verbal notifications, so that the front-end and test personnel can modify the contract separately. As a result, the cost of modifying the contract becomes higher, and people will be more cautious when settling the contract, which will prompt us to improve the interface design capability.

 

As shown in the figure, there is no "joint debugging" link. It is not an error, but a "joint debugging" is no longer a task. After deployment, you only need to change the agent configuration. Even if you use a modern front-end framework (such as vue or react), you only need to configure it during development and then do not need to adjust any code.

 

What about "submit for test? Testing has been ongoing, so there is no longer a "test" link. Regardless of whether either side of the frontend or backend completes the development, the testing personnel can perform the test.

 

It is easy to say that the theory is finally exhausted. tools are needed to help us. There are many tools to describe interfaces, such as swagger and raml, which are well-known. I personally prefer raml.

 

 

 

It is not enough to generate the description tool to generate the mock server. If the description tool is separated from the mock server, it brings about additional work. Fortunately, there is her -- raml-mocker.

Raml-Mocker

Raml-Mocker is a mock server tool developed based on raml using nodejs. You can set the response example command in the raml description interface. raml-Mocker will parse the raml file, start a mock server and return the example content to the browser.

Start Initialize a project

git clone https://github.com/xbl/raml-mocker-starter.git raml-api
cd raml-api
git remote rm origin

  Install

yarn
# or
npm install

  Start mock Server

yarn start
# or
npm start

  Test

curl -i http://localhost:3000/api/v1/users/1/books/
# or
curl -i http://localhost:3000/api/v1/users/1/books/1

  Generate API visualization document

yarn run build
# or
npm run build

 

This function uses raml2html.

 

Configuration-raml-config.json

 

{
  "controller": "./controller",
  "raml": "./raml",
  "main": "api.raml",
  "port": 3000,
  "plugins": []
}

 

• Controller:Controller directory path, which will be described in more details in the advanced Section

• Raml:Raml file directory

• Main:Entry file under the raml directory

• Port:Mock Server Service port number

• Plugins:Plug-ins

Entry: mock Server

 

Raml-Mocker only needs to add example in response:

 

/Books:
/: ID:
Post:
Body:
Application/JSON:
Type: ABC
Responses:
200:
Body:
Application/JSON:
Type: Song
# Returned mock data
Example :! Include./books_200.json

 

Books_200.json

 

{
  "code": 200,
  "data": [
    {
      "id": 1,
      "title": "books title",
      "description": "books desccription1"
    },
    {
      "id": 2,
      "title": "books title",
      "description": "books desccription2"
    }
  ]
}

 

Request through curl:

 

curl -i http://localhost:3000/api/v1/users/1/books

 

You can get the data of example. The only drawback is that different data cannot be dynamically returned based on parameters. Don't worry. Please read it down.

 

Advanced: Dynamic Server

 

If static mock data cannot meet your needs, raml-Mocker also provides dynamic functions.

 

Add the (Controller) command in the raml document to add a dynamic server, for example:

 

/Books:
Type:
Resourcelist:
Get:
Description: gets a user's book.
(Controller): user # getbook
Responses:
200:
Body:
Type: song []
Example :! Include./books_200.json

 

In the document (Controller), it indicates the getbook function in user. js under the Controller directory.

 

Controller/user. js

 

exports.getBook = (req, res, webApi) => {
  console.log(webApi);
  res.send(‘Hello World!‘);
}

 

Raml-Mocker is developed based on expressjs. For details about req and res, refer to the express documentation.

Webapi will return the configuration in the document:

 

{
  "absoluteUri": "/api/:version/users/:user_id/books",
  "method": "get",
  "controller": "user#getBook",
  "responses": [
    {
      "code": "200",
      "body": "... example ...",
      "mimeType": "application/json"
    }
  ]
}

 

In this way, raml-Mocker provides more scalable space, and we can even implement certain logic in the controller.

 

Plug-ins

 

Raml-Mocker provides a plug-in mechanism that allows us to process the response content without using the Controller command, for example, mockjs.

 

Raml-config.json

 

{
  "controller": "./controller",
  "raml": "./raml",
  "main": "api.raml",
  "port": 3000,
  "plugins": ["./plugins/mock.js"]
}

 

/Plugins/mock. js

 

var { mock } = require(‘mockjs‘);

module.exports = (body) => {
  try {
    return mock(JSON.parse(body));
  } catch(e) {}
  return body;
}

Summary

The frontend and backend separation can clarify our responsibilities, break the limitations of the front end, and improve the development efficiency after decoupling work. However, because the development process is not well planned, we fail to make full use of its value and cause more waste.

 

Raml-Mocker can help us solve certain problems in tools, and more importantly, the idea of continuous improvement. Only when the team's thinking is unified can we achieve fast delivery.

 

Why are you suffering more from frontend and backend separation?