An overview of the

Microservices are an architectural style in which the analysis and modeling of complex applications for a particular business domain is decomposed into a set of small, specific, low-coupling services. Each microservice is a small, standalone, and deployable application. The concept of microservice architecture is similar to the concept of separating front end and back end. The front-end application controls all of its own UI-level logic, while the business logic is done through API calls to related microservices. With the growth of front-end single-page application frameworks and the popularity of mobile applications, whether mobile native development or hybrid application development, the front-end and back-end separation makes Web and mobile applications the clients. The client only needs to query and modify resources through the API. The following figure shows the main differences between the absence of BFF and the addition of BFF on the front and back ends.

1. Traditional front-end and back-end separation applications

In traditional front-end and back-end designs, typically mobile applications or websites directly access back-end services, back-end microservices call each other, and then return the final results to the front-end client. Too many HTTP requests can be expensive for clients, especially mobile clients. Therefore, in order to minimize the number of requests, the front end usually prefers to get the associated data through a single API. This means that sometimes the back end will perform some uI-related logic to meet the needs of the client.

2. Front-end and back-end architecture of BFF

The biggest difference between the front-end and back-end architectures of BFF is that the front-end (mobile, Web) no longer accesses the back-end microservices directly, but accesses them through the BFF layer. And each customer will have a BFF service. With BFF, there are fewer calls between microservices. This is because some UI logic is handled at the BFF level.

2.1 BFF and API gateway

Given the above understanding of BFF, what is the difference between BFF and AN API gateway, since BFF is a mid-tier service accessed by the front end and the back end? Let’s first look at common implementations of API gateways. API gateways can be designed in a number of ways. Here are just three examples.)

2.1.1 API Gateway Provides the same API for all clients

For example: / API /accounts. In this case, the API Gateway does not distinguish between client types, as follows:

2.1.2 API gateway provides a separate API for each client

For example: / services/mobile/API/accounts and/services/web/API/accounts. The API gateway determines which client is coming from based on the different apis, and then processes them separately to return the resources required by the different clients.

2.1.3 Multiple API gateways provide separate apis for each client

In fact, BFF is similar to this implementation pattern of AN API gateway.

2.2 GraphQL and REST

GraphQL is the API’s query language and the runtime for completing these queries using existing data. GraphQL provides a complete and easy-to-understand description of the data in your API, enabling customers to ask exactly what they need, and nothing more, making it easier to develop apis and enable powerful developer tools over time.

What are the differences between GraphQL and REST? We can see it in the following example: REST can be accessed in the following way:

Request:

GET http://127.0.0.1/api/accounts
Copy the code

Response:

[
  {
    "id": 88,
    "name": "Mena Meseha",
    "photo": "http://bucket.s3.amazonaws.com/photo.jpg"
  },
  ...
]
Copy the code

For the same request accessed using GraphQL, the process is as follows:

Request:

POST http://127.0.0.1/graphql
Copy the code

Body:

query {accounts { id, name, photo } }
Copy the code

Response:

{ "data": { "accounts": [ { "id": 88, "name": "Mena Meseha", "photo": "http://bucket.s3.amazonaws.com/photo.jpg" }, ... ] }}Copy the code

Compared to the REST style, GraphQL has the following features:

2.2.1 On Demand data model definition

For example, for the above /accounts access, if the client is only interested in account.id and account.name. Therefore, the client only needs to pass account {id \n name} to query. The model is defined in the background. The client only needs to get the data it cares about.

2.2.2 Obtaining many resources in one request

For example, you might need to get account.friends and Account.friends.address. In fact, this query needs to be retrieved from three different resources, which are the data Account, Friends, and Address. In REST mode, you might need to send the account data again to another API to get the friend and address information. GraphQL can query nested data levels, so it greatly reduces the number of client requests and allows clients to get all the data they need through a single API, as shown below:

{
  account(id:88) {  // 1st Level
    name,
    friends {  // 2nd Level
      name,
      address {  // 3rd Level
        country,
        city
      }
    }
  }
}
Copy the code

2.3 GraphQL compared to REST

To compare GraphQL and REST, the main differences are as follows:

• 1. Data acquisition: REST lacks scalability and has on-demand access to GraphQL. The payload can be extended when the GraphQL API is called.
• 2.API calls: While the REST operation for each resource is an endpoint, GraphQL requires only one endpoint, but the publishing body is different.
• 3. Complex data requests: REST requires multiple calls to nested complex data, while GraphQL makes one call, reducing network overhead.
• 4. Error code handling: REST can accurately return HTTP error codes, GraphQL uniformly returns 200 and wraps error messages.
• 5. Version number: REST is implemented with V1 / v2, while GraphQL is implemented with Schema extensions.

2.4 Microservices + GraphQL + BFF practice

I recommend building the BFF side of the project using Express-GraphQL, then deploying it via Docker, and registering and discovering services via Consul between BFF and the microservice back end.

3. GraphQL + BFF practice

You can consider some of the better qualities of graphQL-based BFF by:

3.1 GraphQL and BFF focus on business points

From a business point of view, the property manager (PM App) is closely related to property, because the property manager manages a group of houses, so it is necessary to know the profile of all the houses, and for each house it is necessary to know if there is a house. Corresponding maintenance applications. Therefore, PM App BFF data structures are defined, and maintemamceRequests are property child attributes. For similar data, the home maintenance provider (the vendor application) focuses on maintenance requests (maintenance work orders), so in the data obtained by the vendor application, our principal is the maintenanceRequest. Therefore, different clients have different concerns about the same data because of different usage scenarios. From this perspective, the data structures defined in the BFF are what the customer really cares about. BFF is a part of our customers. It should be noted that “business focus” does not mean that BFF will handle all business logic. Microservices should still handle business logic. BFF focuses on customer needs.

3.2 GraphQL supports version control

Assume that the BFF end has been published to production. Now we need to change the structure of Figure (1) to that of Figure (2), but in order not to affect API access for older users, our BFF API must be compatible at this point. If it’s REST, we might update the API version. But in BFF, we can use the structure of Figure (3) to achieve forward compatibility. At this point, the old APP uses the data structure of the yellow area, while the new APP uses the structure defined by the blue area.

conclusion

Building BFF based on GraphQL under microservices is not a panacea. It may not be suitable for every project. For example, after using GraphQL, you might have to face multiple query performance issues, but that doesn’t stop it from being a good try. You do see that Facebook already uses GraphQL, and Github has the GraphQL API turned on. This article is just an introduction to that idea. I would like to share the use of BFF more in the community.