Gateway is a single window for different APIs. Backend-for-Frontend uses Gateway to process requests and prepare responses intended for the frontend.
Gateway and Backend-for-Frontend (BFF) are design patterns for web application development. Both patterns are used to provide access to different APIs using a single contract. A contract is everything that allows two network nodes to communicate with each other: the architecture of building a network connection, a set of network protocols, a set of addresses and ports for accessing data, rules for forming requests from clients, a mechanism for preparing and sending responses from the server.
How to understand
A modern web application consists of an interface that the user works with and a backend that the user does not see. The backend can be arranged in different ways, it all depends on the task. The backend of large web applications is usually quite complicated.
As a rule, the backend is a collection of different programs (microservices) or one big program (monolith). The microservice approach is increasingly being used in the modern web, which you can read about in the article “Microservices”. The problem with such a complex backend is that each microservice provides a unique programming interface. The frontend has to work with each microservice separately and remember each API. This is inconvenient, creates a tight connection between the frontend and the backend, and requires a lot of knowledge about the internal structure of the backend. The solution to this problem is to make one unified interface, which in turn will access all microservices.
Communication of the frontend with microservices directly
One of the first such solutions was Gateway, which is usually a proxy server and provides a single window for accessing data via a specific software interface (Application Programmable Interface – API), forwarding data from the frontend to the desired microservice and back. The appearance of the user’s application is changing, the business logic is changing, the client application is changing, the contract may also change, but this does not affect the rest of the API in any way. Gateway forwards requests from clients to other APIs, taking into account the difference in contracts, and this reduces the engagement of the backend and frontend in the web application. As a rule, frequent requests can be cached on the Gateway side, simple business logic can be implemented that provides control over the set of data being forwarded between the client and the external API.
Using Gateway
The work of Backend-for-Frontend, which is the development of the idea of a single window, is similar to Gateway in the tasks of providing a single contract and control over a data set. The BFF necessarily includes a Gateway, which has the following requirements:
- Common templates on the client and server (for example, JSX).
- High response rate under load.
- A single language on the BFF client and intermediate server.
- Using Backend-for-Frontend
Common templates are very important because it significantly speeds up development and facilitates support for both the client side of the application and the BFF server application. Considering that the language should be the same, this allows you to reuse the code on the client and server. High response speed is achieved not only by caching frequent requests, but by means of preliminary preparation of data for requests from the client.
You can use BFF not only to access various APIs. For example, the BFF pattern fits perfectly into the architecture of building a web application in which microservices work on the server side. You can read about them in the article “Microservices”.
How to get started
Section of the article “How to get started”
If JavaScript is used as the development language, then it is obvious that it is necessary to ensure the execution of the code. Most likely, you will use Node.js, but there are alternatives: Deno or GraalVM. Node.js is great for a large number of I/O operations, but not in the case of calculations. For BFF, this is a great choice.
The next step is the choice of architecture. This stage is very important because the choice of architecture determines the further support and development of the application.
The concept of layers is perfect for BFF. In this concept, there is a separation of the user interface (in our case, the API that the client accesses) from business logic and data. A server application is usually built on layers and connections between them. There are several approaches for implementing layers.
Three—tier (three-tier) architecture is historically one of the first approaches that is built on the collaboration of three layers: the client layer, the business logic layer and the data layer. The bottom layer is the data layer. It interacts with the business logic layer, which in turn interacts with the client layer. In a three-tier architecture, the client layer is isolated from the data layer.
Three-level (three-tier) architecture
The problems of this approach are obvious. The whole application is built in relation to data. For example, the structure in the database will completely define all the upper layers, which is fundamentally wrong. This does not allow for the proper level of abstraction. There will be problems if some external API or method of receiving data from a microservice changes. It will be extremely difficult to develop and maintain such an application.
Domain-Driven Design (DDD) is a more modern approach when the application is divided into four layers: user interface (client), business logic, domain, infrastructure. In this approach, the bottom layer is the infrastructure layer, above which the domain layer is located (it defines all the entities necessary for the business logic layer to work within the domain domain).
Domain-Driven Design (DDD)
This approach is not bad, but it is too heavy for BFF. Often the requirements for a product are such that the definition of the domain and the main business logic should lie on the backend. The task of the BFF is to be a convenient and easy layer between the frontend and the backend.
It is important to note that the infrastructure sometimes needs to be visible from the business logic layer, which leads to a problem called abstraction leak, or current abstraction. The problem is related to the fact that for the architecture to be correct from the point of view of future support and development of the code, it is necessary to isolate the layers. Only the top and bottom layers can know something about the current one, but not the others.
Pure architecture is an even more modern approach, which uses the same four layers as in DDD, but in a different way. The infrastructure layer rises to the level of the user interface. This avoids abstraction leaks. The domain becomes the center of the application. Modern BFF applications use a clean architecture.
Clean architecture
Express is often chosen as a framework in conjunction with Nest.js . Of course, designing a specific application depends on the business task and domain domain of the web application.