Frontier: Hello, I’m Tree jam. Today’s hydrology is about the battle between the front end and the back end. Since the separation of the front end and back end, this separation has caused a lot of communication problems and even battle. Let’s take a look at the past and present of the front and back battle

1. Ancient Times (Web1.0-MVC architecture)

I vaguely remember when I graduated from college, the first IDE installed on my computer was not Webstorm or VScode, but IntelliJ IDEA. Because the development of front-end projects, need to run a complete JAVA program, various Maven configuration, and then write JSP files on the basis of front-end development, in other words, “secondary development”, now think of the time to compile the scene, I remember. In other words, front-end development is heavily dependent on the environment

Arlo: I remember just providing THE HTML code, using Sublime as the editor, and finally integrating it into the JSP

This is another model where the front end outputs the DEMO Html and then gives it to the back end to template

It just says that the integration is completely handed over to the back end, which has a high error rate. It is also very troublesome to solve bugs, and both sides need to cooperate to deal with them. In exchange for more communication costs. Because the responsibilities of the front and back end are easily entangled, they are too coupled and can lead to battle.

Summary of the points that produced the battle 👇 :

  • 1. Front-end development is heavily dependent on the environment, resulting in a long compilation time for each modified file, which tests the patience of front-end developers
  • 2. When an application needs to be upgraded, the front-end and back-end applications cannot be upgraded independently. Instead, you apply an overall upgrade to the entire unit
  • 3. The back end of the front-end pre-developed HTML page, embedded in the JSP file, the actual style effect deviation is too large

2. Iron Age (Web2.0-MVVM architecture)

The emergence of the front-end MVVM architecture promotes the separation of front-end development and back-end business logic, realizing the true “separation” : division of assistance, each to perform their own duties, and refuse to bind.

This is where you need a “communication bridge” : an API, and ajax calls to communicate between the front and back ends. They’re also decoupled

API consumer (front end) : Understands interface information through interface documentation, focuses on receiving data, processing data, and processing rendering logic

API producer (back end) : provides interface and interface documentation Focal point: provides data, provides API documentation

The development process is also beginning to change 👇 :

  • The back end writes and maintains interface documentation, updating it as the API changes
  • The back end develops the interface according to the interface document
  • Front-end development based on interface documentation + Mock platform
  • After the completion of development, joint adjustment and submission test

Ah Le: After the separation of the front and back ends, do the students at the back end or the front end develop first?

As we can see from the development process above, interface documentation is the most critical communication bridge after separation. According to the principle of “important First”, documentation becomes the primary factor. It is recommended that interface documentation be First, that is, API-first. Without interface documentation, the front-end can hardly be started.

Is there a better tool for postman debugging, Yapi or RAP2 to generate maternity leave data?

I used to have a Postman on my left hand and a yapi on my right, with code in the middle

You can try Apifox

Postman + Swagger + Mock + JMeter Apifox is a platform for Postman + Swagger + Mock + JMeter

The front-end students can use Apifox to solve the interface debugging + data Mock requirements

Here is a screenshot of the actual combat page

But the new development process also revealed new battle points

Summary generated battle points:

  • 1. A page needs to request too many interfaces. The front-end expects the back-end to do interface aggregation to reduce the number of requests

  • 2. The interface provided by the back end is changed, but the interface document is not synchronized, or the interface provided by the back end is missing, and the front end cannot mock normally

  • 3. Inconsistent fields: for example, some fields of a mobilePhone number return mobilePhone, while others return PhoneNumber. Inconsistent fields increase communication costs

3) Silver Age (BFF Era)

With the popularity of microservices, the back-end data interface is split and separated. Assuming that the front-end needs some data now, it may rely on several microservices and need to make data aggregation. At the same time, as the front end closest to the user, facing various mobile devices, each client has different data type requirements. For example, the mobile terminal does not require much data, so it needs to do data disassembly.

A battle scenario like the one below is generated 👇 :

The front-end and the back-end have their own arguments, and there is no solution to this awkward situation, hence the BFF, which stands For Backends For Fronends.

Below the BFF layer is a variety of back-end micro services, on the upper layer of BFF is a variety of front-end applications (multi-terminal applications), downward call back end for services, up to provide interface services to the client, the back end for the BFF layer front-end provided RPC interface, BFF layer directly call the server RPC interface to get data, as needed data processing. To complete the whole BFF closed loop (Node+GraphQL technology stack)

The advent of BFF really solved the communication cost of a lot of front-end, and made each other a lot friendlier, and the conversation evolved like this

  • Back end: These micro services are here, you look at the combination, if you have any questions, call me

  • Front end: Ok, I look at the combination

Children interested in BFF can read tree sauce before you learn BFF and Serverless?

Previous popular articles 📖 :

  • These Node open Source tools are worth owning
  • Developing visual Data Screens from 0 to 1 (PART 1)
  • Developing visual data Screens from 0 to 1 (part 2)
  • Construction of front-end Knowledge System of Tree Jam (PART 1)
  • Construction of front-end Knowledge System of Tree Jam (Part 2)
  • Talk about daily collaboration tools for front-end development
  • Babel configuration is stupid
  • How to better manage the Api
  • The interviewer asks you about Node
  • Front-end engineering stuff
  • Did you learn BFF and Serverless
  • Front-end operations and deployment

Hello, I am 🌲 tree sauce, please drink a cup 🍵 remember three lian oh ~

1. Remember to click a thumbs-up after reading oh, there is 👍 motivation

2. Pay attention to the interesting things at the front of the public account, and chat with you about the interesting things at the front

3. Github frontendThings thanks to Star✨