The front and back ends, why are you too anxious...

Frontier: Hello, I'm Shuchan. The hydrology shared today is about the battle between the front end and the back end. Since the separation of the front end and the back end, this separation has brought a lot of communication problems, and even caused a battle. Let’s review the past and present of the front and back battles

1. Ancient times (web1.0-MVC architecture)

I vaguely remember that when I just graduated from university, the first IDE installed on my computer was not Webstorm or VScode, but IntelliJ IDEA. Because to develop front-end projects, you need to run a complete JAVA program, various maven configurations, and then perform front-end development based on the JSP files written in the back-end, in other words "secondary development", now think about the slow compilation at the time The scene is vivid. In other words, front-end development relies heavily on the environment

Classmate Ale: I remember that I only provided HTML code at the time, and then used Sublime as the editor, and then finally integrated into the JSP.

This is another mode, the front end is responsible for outputting the demo Html, and then handed over to the back end to set the template

It just means that it is completely handed over to the back-end to integrate, and the error rate is high. It is also very troublesome to solve the bug, and it needs to be processed by both parties. In exchange for more communication costs. Because the front-end and back-end responsibilities are easily entangled and the coupling is too strong, it may eventually lead to battle.

Summarize the points that produced the battle 👇:

• 1. Front-end development relies heavily on the environment, which leads to too long compilation time for each modified file, which tests the patience of front-end developers
• 2. When the application needs to be upgraded, the front-end and back-end cannot be upgraded independently. It is an overall upgrade of the entire single application
• 3. After the back-end embeds the pre-developed html page in the front-end into the JSP file, the actual style effect deviation is too large

2. The 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, and truly realizes "separation": division of labor, assistance, and rejection of bundling.
At this time, a "communication bridge" is needed: API, and then through ajax calls to achieve collaborative communication between the front and back ends. The two are also decoupled

API consumers (front-end): understand interface information through interface documents, focus on: accepting data, processing data, and processing rendering logic

API producer (back-end): Provide interfaces and interface documents. Focus: Provide data and API documents

The development process has also begun to change 👇:

• Back-end writing and maintaining interface documents, and updating interface documents when API changes
• The back-end develops the interface according to the interface document
• The front end is developed according to the interface document + Mock platform
• After the development is completed, joint debugging and submitting for testing

Ah Le: After the front and back ends are separated, should the back-end students develop first or the front-end students develop first?

From the above development process, we can see that after the division, the interface document is the most critical communication bridge. According to the important first principle, the documentation becomes the primary factor. It is recommended that the interface document first, that is, API-First, can hardly start without the front end of the interface document.

Ah dumb student: For the front-end classmate interface to call postman debugging, the mock uses Yapi or RAP2 to produce fake data, is there a better tool in one step?

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

You can try Apifox

Official introduction: Apifox is an integrated collaboration platform for API documentation, API debugging, API Mock, and API automated testing, positioning Postman + Swagger + Mock + JMeter

Front-end students can use Apifox to solve the interface debugging + data mock

Share a screenshot of the actual combat page below

But the new development process also exposes new battle points

Summarize the battle points generated:

• 1. There are too many interfaces that need to be requested for a page. The front-end hopes that the back-end does interface aggregation to reduce the number of requests. The back-end thinks that the interfaces are divided according to microservices, without coupling.
• 2. The interface provided by the back-end has changed, but the interface documents are not synchronized, or the interface provided by the back-end is missing, and the front-end cannot be mocked normally, etc.
• 3. Fields are not uniform: For example, some fields of mobile phone number return mobilePhone, and some return PhoneNumber. Fields are not uniform, which leads to increased communication costs.

3. The Silver Era (BFF Era)

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

Will produce a battle scene similar to the following 👇:

Front-end classmates and back-end classmates have their own reasons. Is there a solution that can resolve this awkward scene? So there is BFF. The full name of BFF is Backends For Frontends (serving the backend of the front end)

Below the BFF layer are various back-end microservices, and on the upper layer of the BFF are various front-end applications (multi-terminal applications). The back-end is called downward as a service, and the client is provided with interface services upward, and the back-end is provided by the front-end of the BFF layer. The BFF layer directly calls the server RPC interface to get the data, and processes the data on demand to complete the closed loop of the entire BFF (based on the Node+GraphQL technology stack)

The emergence of BFF does solve a lot of communication costs after the front-end, and they are also a lot friendly to each other, and the dialogue has evolved into this

• Backend: These microservices are all here, you look at the combination, and if you have any questions, come to me
• Front end: OK, I look at the combination

For children's shoes interested in BFF, you can read before the tree sauce. Have you learned BFF and Serverless?