Introduction to API Gateways and Microgateways

About the API Gateway

An API gateway lets API calls enter and leave to reach their corresponding destination points, better known as microservices, in a system. An API gateway is mainly responsible for routing API calls. Its secondary responsibilities include security, caching, load balancing, rate-limiting, dynamic discovery and routing, management, and scaling the number API calls.

An API gateway is like a security officer that allows individuals to enter a building once they have validated their identification. A driver's license or other ID can indicate they are over the legal age. In the same way, when a subscriber of an API Gateway (in this case, WSO2 API Manager) accesses an API from the API store, an API call is sent to the gateway. The gateway then sends the API call’s token to the Key Manger, who validates it by reviewing the database of subscribers. Following a successful validity check, the API gateway routes the API call to its corresponding microservice. This can be illustrated by Figure 1.

Figure 1: The WSO2 API Manager and WSO2 Microgateway integration and call flow diagram

Use Cases - Bank

In a system that handles multiple API calls, the same use case does not repeat itself. Depending on the requirements of the processes, API calls differ. As a result, the API Gateway provides a mechanism to capture various use cases and handles API calling accordingly. For example, say a bank may use WSO2 API Manager for their transactions. They may handle several calls per second, which causes significant traffic to the system network. To accommodate this, the bank may decide that if there are calls for loan inquiries, no security checks take place for these calls. Additionally, if there is a significantly large transaction by a customer, the bank may add security protocols to determine that the user authorizing the transaction is who they say they are and did in fact authorize the transaction.

In the above scenario, the same system handles two varying use cases by adopting different levels of security. This is what the API Gateway achieves. When an API call is received by the API Gateway, it acquires attributes of the call (purpose of transaction, user details etc.) and based on it, decides whether they should consider security or not. However, a significant weakness of an API Gateway is when a new microservice is added or modified, the API Gateway must be updated every time, which is time consuming and costly. This is where the API Microgateway comes in.

About the API Microgateway:

The API Microgateway is a customized version of the API Gateway. It is essentially a lighter version of the API Gateway. This means that it makes alterations to API calls and routes them to the appropriate destination points. In a system, each microservice can have each API Microgateway to manage requests including:

• Message security
• Transport security
• Routing - Directing API calls to corresponding microservices.
• Throttling - Setting a limit for successful API calls so the WSO2 API Microgateway can control traffic
• Able to work in a lockdown environment - A “Lockdown” environment is a controlled or minimum privileged environment. For example, a system’s administrator limits the functionalities of clients to provide better security. WSO2 API Microgateway can work in a lockdown environment since the connectivity between WSO2 API Manager and WSO2 API Microgateway isn’t mandatory.
• Fitting the microservices architecture - The startup latency is low as theWSO2 API Microgateway occurs once and consumes minimal resources. Therefore, the boot-up time will be faster than the traditional API gateway.
• Supports CD/CI - With this feature, any server and node failure will not cause the system to crash.
• Other common API management related servicessuch as supporting SOAP backends, REST API support, supporting custom mediations, schema validations, and JWT revocation.

That said, there are occasions to use API Gateway and API Microgateway. Let us review these.

When to Use an API Gateway: 

• To throttle API calls based on counters across all gateway nodes (depending on requirements).
• To possess a centralized component to control inbound and outbound API calls, and serve as a connector between multiple APIs and backends
• To mediate and orchestrate the flow when following SOAP architecture

When to use a Microgateway: 

• If there is no connectivity between the API gateway and the Key Manager, during an offline state of the system or in a lockdown environment, an API Microgateway is the most suitable option to use here.
• To run a set of selected APIs in unusual traffic
• In internal or on-premise API Gateway deployments where consumers (delivery channels) and service instances reside within the same network. In such cases, having the Microgateway within close proximity to a backend server reduces latency.
• When there is a requirement to run a Gateway in sidecar mode along with an application server within the same runtime, or the same pod in Kubernetes.

I hope this blog has defined an API Gateway, a Microgateway, their capabilities, their advantages and disadvantages, and the optimal use cases for both.