API Gateway Mode

What is a gateway

The term gateway is derived from the definition of the computer network, the gateway is also called the Inter-Network connector, protocol converter. The exact definition of a gateway is a connection between two computer programs or systems, and the gateway acts as a portal between two programs, allowing them to share information through protocol communication between different computers. As the name implies, API gateways are the levels and barriers that APIs call each other.

Why gateways are required between APIs

Imagine that we are implementing a very large business system, divided into different business domain and subsystem, each domain and subsystem provides the API to handle the business, and the data interaction between different systems in the way of API. In general, we may integrate all APIs that implement business functions (API Center) to provide data processing capabilities to different channel portals. When one day our systems need to interact with third parties, we need to expose the exposed APIs to external system calls, as well as call external APIs to implement their own business requirements. At this point we will consider a number of issues, such as: authorization and authentication of access between services, security and performance monitoring, cache and log processing, timeout retry, load and fuse processing, query request aggregation and a series of problems. At this point you need to be able to focus on all the things that you might need to deal with in the service invocation, like the property and security of the community, and that all the owners of the community have to deal with everything within their purview.

This is usually the case that the API gateway needs to help us deal with, as the system business continues to complicate, the more our system is larger, the interaction of the API is more and more complex. At this point we may consider splitting this huge system into smaller domain, providing the respective domain APIs. This is the most popular topic nowadays: microservices. When our systems evolve into microservices architectures, API Gateways are a critical part of the system. In a microservices architecture, client applications typically require the ability to use multiple microservices. If a client consumes a service directly, that would normally require processing and coordination with multiple microservices endpoint. What happens when an application introduces a new microservices or updates an existing microservices? Imagine if your application has a lot of microservices, then it's a nightmare for the system to handle and coordinate requests from so many endpoint from clients. And because the client application will be coupled with these endpoint, this will make our system edge chaotic.

Therefore, we need a middle tier or an indirect layer (Gateway) to handle the different client requests for the API, which will make our application very easy to handle. Without an API gateway, the client application must send a request directly to the microservices, which creates a lot of confusing problems, such as:

Coupling: If there is no API gateway, the client's application will be coupled to the internal microservices. The client-side order needs to know which parts of the service the APIs that implement the business requirements are scattered over, and when we develop and refactor the internal service, it will affect the client application and is difficult to maintain because the client application needs to track the endpoint of multiple services

multiple requests: a page in a client application may need to invoke multiple services several times to complete a feature, which can result in multiple round-trip requests between the client and the server, adding significant latency. We know that aggregations processed at the intermediate level can improve the performance and user experience of client applications.

Security Issues : If there is no gateway, all services must be exposed to the "outside world", which makes the attack surface larger than the hidden internal service, which is not used directly by the client application. The smaller the attack surface, the more secure the application.

crosscutting concerns: each publicly released service must handle issues such as authorization, SSL, and so on. In many cases these concerns can be handled in one layer, so that internal services can be simplified, which reminds me of aspect-oriented programming (AOP)

What is Gateway mode

When we design and build large or complex microservices-based applications using multiple client applications, consider using API gateways, a service that provides a single point of entry for some microservices groups, similar to the facade (appearance Class) pattern of object-oriented design, but is part of the system in microservices. A variant of the API Gateway pattern is also known as "backend for Front-End" (BFF), because you might create multiple API gateways based on the different requirements of each client application. The API gateway, therefore, sits between the client application and the microservices, which acts as a reverse proxy to route requests from the client to the service, and it can also provide additional crosscutting features such as authentication, SSL termination, and caching.

The following figure shows how a custom API gateway fits into a microservices-based architecture.

In the example above, the API Gateway will run as a custom Web API or as a container for the ASP. NET Webhost Service

It should be emphasized in this diagram that we will use a custom API Gateway service for many different clients. This can be an important risk because your API Gateway service will grow and evolve based on the client's needs, and eventually it will become bloated due to these different requirements, in fact it may be very similar to a monolithic application or monolithic service. That's why we highly recommend splitting the API gateway into multiple services or multiple smaller API gateways.

We also have to be very careful when using the API gateway pattern, and it is often not a good practice to aggregate all the internal microservices of an application with a single API gateway, because once this is done it acts as a monolithic aggregator or coordinator and violates microservices autonomy by coupling all microservices. The API gateway should therefore be isolated based on business boundaries and client applications, rather than as a single aggregator of all internal microservices . When the API gateway layer is decomposed into multiple API gateways, if your application has multiple clients, this can be a major hub to identify the gateway types of multiple APIs, so you can have different skin classes to meet the needs of each client. This is what we call the "backend for front-end" pattern (BFF), where each API gateway can provide different APIs for each client, and may even implement specific adapter code based on the specific needs of the client, which calls multiple internal microservices below, as shown in:

Demonstrates a simplified architecture with multiple fine-grained API gateways, in which case identifying the boundaries of each API gateway is purely BFF-based, and therefore only provides the API required for each client, but in larger applications it should also go further, To create a gateway based on a business boundary as a second design measure.

Key features in the API gateway pattern

API Gateways can offer a variety of features depending on the product, which may provide richer or simpler features, but the most important and basic feature for any API gateway is the following design:

reverse proxy or gateway route: The API Gateway provides a reverse proxy that redirects or routes requests (usually HTTP requests) to the endpoints of the internal microservices. The gateway provides a endpoint or URL for the client application, and then internally maps the request to a set of internal microservices. This routing feature helps decouple the client from the microservices approach, and also facilitates the control of the gateway between the single API and the client, so you can add new APIs as new microservices while still using the legacy single API. Until it is divided into many microservices in the future. Because of the presence of the API gateway, the client application does not notice that the API used is implemented as an internal microservices or a single API, when it evolves and reconstructs our single API to MicroServices because of the existence of API Gateway routing, Does not bring changes to the URI of the client request. To learn more about gateway-routed things please poke here.

Request aggregation: as part of the gateway pattern, you can aggregate multiple client requests (typically HTTP requests) against multiple internal microservices into a single client request. This mode is especially handy when the client page needs to invoke data from multiple microservices. Using this method, the client sends a request to the API gateway, and then the gateway is responsible for sending multiple requests to get the internal microservices and then aggregating the results back to the client. The main advantage and goal of this design pattern is to reduce the gap between the client application and the back-end API, which is especially important for remote applications outside the data center where microservices are located, such as requests from mobile applications or spa applications from JavaScript in client remote browsers. This pattern is not important for regular web applications (such as ASP) that perform requests in a server environment, because latency is much smaller than remote client applications. The ability to perform this aggregation depends on the API gateway product that you use, but in many cases it will be more flexible to create aggregation microservices within the scope of the API gateway, so you can also define aggregations (that is, C # code) in your code. To learn more about the request aggregation, please poke here.

crosscutting concerns or gateway offload: Depending on the features provided by each API gateway product, you can move functionality from a single microservices to a gateway, simplifying the implementation of each microservices by merging crosscutting concerns into a single layer. This is especially handy for complex special features that can be implemented correctly in each of the internal microservices, such as the following features.

Authentication and authorization
Service Discovery Integration
Response cache
Retry policies, Circuit breakers, and QoS.
Speed limits and throttling
Load Balancing
Logging, tracking, correlation
header files, query strings, and declaration transformations
IP White List

Depending on each implementation API Gateway product can provide more crosscutting concerns, but these are the most common features. For example, Azure API Management provides most of these features, as well as many advanced features that are useful for commercial APIs. But for a simpler approach, a lightweight API gateway like Ocelot is quite flexible, because you can deploy it to your chosen environment and your microservices. For more information about Gateway Offload mode, please poke here.

This article mainly introduces the characteristics of the API Gateway pattern, the article is from the official Microsoft blog and added a little understanding of their own. Translation from: https://blogs.msdn.microsoft.com/cesardelatorre/2018/05/15/ Designing-and-implementing-api-gateways-with-ocelot-in-a-microservices-and-container-based-architecture/

Resources:

API Gateway

Http://microservices.io/patterns/apigateway.html

Https://docs.microsoft.com/en-us/azure/architecture/microservices/gateway

Aggregation and Composition pattern

Http://microservices.io/patterns/data/api-composition.html

API Gateway Mode