The first session of the front-end technology sharing conference of Master Education has been closed on January 23. The following is the edited version of the lectures delivered by the big lecturers. Thank you for your support:

introduction

Tang Bing, front-end technical experts, from qianhe middle front location network business team Responsible for team electricity related business development, team head BFF layer technology Team daily work content, the main portal to the company, the electricity business provide the front support, marketing, distribution and other business, the business covers PC, H5, App, small procedures, NodeJS, etc. Various technical scenarios.

The following is part of tang Bing’s speech:

The historical evolution of BFF

At the front-end BFF layer, we go through roughly four stages:

  1. ServerAPI: The back-end directly exposes the interface to the front-end development for business calls, which is also the most common mode for front-end development.
  2. InternalRest: On the basis of the underlying service data interface, the back-end students perform logical aggregation of business pages, and then transmit them to the front end for page data rendering.
  3. Apoll-graphql: business interface aggregation is structured and modularized. At present, this part is led by our qixun Location network front-end developer students. The background here is that at present, the company’s back-end services are basically developed by microservitization, and the interface data are delivered atomically.
  4. Apoll-federation: Split support services based on Graphql to provide a better development experience

At present, the front end of Qianxun location network is in the third to the fourth stage of transition

InternalRest

Corresponding to the backend development of students, the development of strong coupling page shows the logical way to develop the API, development experience is very poor, have interference, internalRest can help develop students do development stratification, the splicing data, the logic of this layer from the data of core modules, inside the backend data model can be has nothing to do with the specific page logic;

In the initial stage of front and back end separation, this approach can greatly accelerate business development, but with the continuous development of business, many non-business model necessary fields are difficult to maintain; This is typical [the working boundary between data producers and data consumers is not clear]

Apoll-Graphql

Why graphQL,

  1. Graphql allows front-end developers to customize data fields. It provides a configurable way to define and tailor data structures without writing redundant code
  2. Graphql can very conveniently help us to achieve data aggregation of business pages. For example, we have a shopping mall system with shopping list, shopping cart, announcement information and so on. Here, we can get all data through a GraphQL definition interface to reduce the number of interface requests
  3. Combined with graphQL’s mandatory description of data types, we can understand the specific meaning of each data very clearly and intuitively

NestJs-Graphql

Why NestJs is recommended:

In the actual project development, we found that when developing the Server layer, the development mode of strongly typed language is more data-friendly. Compared with Koa, NestJs has better support for data types. In addition, NestJs provides many general module functions, such as using Guard for user verification, filter for data exception processing and so on

Apoll-Federation

At present, under many business scenarios of Qihiro Location network, the front-end BFF layer program is not directly exposed to the outside, but is distributed through web-GW (gateway), and then interface aggregation is done through the gateway layer, so that in case of a service error occurs in production, we can still ensure that other services will not be affected

Gateway aggregates concrete business data through data Schema definition, and it supports cross-project schema format acquisition, which greatly facilitates cross-project development

Gateway not only defines the schema structure in the project code, but also provides remote push-pull mode to pull the schema structure. However, Apollo does not officially provide independent deployment solution, so we need to develop a set of schema integration system by ourselves. Qiqiseek also implemented a set of its own. It’s a little bit individual

More exciting content, welcome to follow