API Gateway

-
An API gateway is a service which is the entry point into the application from the outside world. It’s responsible for request routing, API composition, and other functions, such as authentication. Let’s take a look at the API gateway pattern.
Overview of the API gateway pattern
The drawbacks of clients making multiple requests in order to display information to the user are well known (I describe them in my book!). A much better approach is for a client to make a single request to what’s known as an API gateway. An API gateway is a service which is the single entry-point for API requests into an application from outside the firewall. It’s similar to the Facade pattern from object-oriented design. Like a facade, an API gateway encapsulates the application’s internal architecture and provides an API to its clients. It might also have other responsibilities, such authentication, monitoring, and rate limiting. 
Figure 1 shows the relationship between the clients, the API gateway, and the services

The API gateway is responsible for request routing, API composition, and protocol translation. All API requests from external clients first go to the API gateway. The API gateway routes some requests to the appropriate service. The gateway handles other requests using the API Composition pattern and invoking multiple services and aggregating the results. It might also translate between client-friendly protocols such as HTTP and WebSockets and client-unfriendly protocols which are used by the services.
Request routing
One of the key functions of an API gateway is request routing. An API gateway implements some API operations by routing requests to the corresponding service. When it receives a request, the API gateway consults a routing map that specifies which service to route the request to. A routing map might, for example, map an HTTP method and path to the HTTP URL of a service. This function is identical to the reverse proxying features provided by web servers such as NGINX.
API Composition
An API gateway typically does more than reverse proxying. It might also implement some API operations using API composition. In my book, I use an example application called FTGO to teach how to move from monolithic architecture to microservices. The FTGO API gateway, for example, implements the Get Order Details API operation using API composition. As figure 2 shows, the mobile application makes one request to the API gateway, which fetches the order details from multiple services

The FTGO API gateway provides a coarse-grained API that enables mobile clients to retrieve the data they need with a single request. For example, the mobile client makes a single getOrderDetails() request to the API gateway.
Protocol translation
An API gateway might also perform protocol translation. The API gateway might provide a RESTful API to external clients even though the application services use a mixture of protocols internally include REST and gRPC. When needed, the implementation of some API operations translate between the RESTful external API and the internal gRPC-based APIs.
The API gateway provides each client with client-specific API
An API gateway could provide a single one-size-fits-all (OSFA) API. The problem with a single API is that different clients often have different requirements. For instance, a third-party application might require the Get Order Details API operation to return the complete Order details, while a mobile client only needs a subset of the data. One way to solve this problem is to give clients the option of specifying in a request which fields and related objects the server should return. This approach is adequate for a public API that must serve a broad range of third-party application, but it often doesn’t give clients the control they need.
A better approach is for the API gateway to provide each client with its own API. For example, the FTGO API gateway can implement provide the FTGO mobile client with an API which is specifically designed to meet its requirements. It might even have different APIs for the Android and iPhone mobile applications. The API gateway also implements a public API for third-party developers to use.
Implementing edge functions
Although an API gateway’s primary responsibilities are API routing and composition, it may also implement what are known as edge functions. An edge function is, as the name suggests, a request processing function which is implemented at the edge of an application.
Examples of edge functions that an application might implement include:
  • authentication – verifying the identity of the client making the request
  • authorization – verifying that the client is authorized to perform that particular operation
  • rate limiting – limiting how many requests per second are allowed from either a specific client and/or from all clients
  • caching – cache responses to reduce the number of requests made to the services
  • metrics collection – collect metrics on API usage for billing analytics purposes
  • request logging – log requests
Three different places in your application allow you to implement these edge functions.
The first option is to implement these edge functions in the backend services. This might make sense for some functions such as caching, metrics collection, and possibly authorization, but it’s generally more secure if the application authenticates requests on the edge before they reach the services.
The second option is to implement these edge functions in an edge service which is upstream from the API gateway. The edge service is the first point of contact for an external client. It authenticates the request and performs other edge processing before passing it to the API gateway.
An important benefit of using a dedicated edge service is that it separates concerns. The API gateway focusses on API routing and composition. Another benefit is that it centralizes responsibility for critical edge functions such as authentication. This particularly valuable when, as I describe below, an application has multiple API gateways that are possibly written using a variety of languages and frameworks. The drawback of this approach is that increases network latency because of the extra hop. It also adds to the complexity of the application.
As a result, it’s often convenient to use the third option and implement these edge functions, like authorization, in the API gateway itself. One less network hop exists, improving latency. Fewer moving parts reduces complexity.
API gateway architecture
An API gateway has a layered, modular architecture. Its architecture, which is shown in figure 3, consists of two layers, the API layer and a common layer. The API layer consists of one or more independent API modules. Each API module implements an API for a particular client. The common layer implements shared functionality including edge functions such as authentication.



In this example, the API gateway has three API modules:
  • Mobile API, which implements the API for the FTGO mobile client
  • Browser API, which implements the API to the JavaScript application running in the browser
  • Public API, which implements the API for third-party developers.
An API module implements each API operation in one of two ways. Some API operations map directly to single service API operation. An API module implements these operation by routing requests to the corresponding service API operation. It might implement these API operations using a generic routing module that reads a configuration file describing the routing rules.
An API module implements other, more complex API operations using API composition. The implementation of this API operation consist of custom code. Each API operation implementation handles requests by invoking multiple services and combining the results.
API gateway ownership model
An important question that you must answer is who is responsible for the development of the API gateway and its operation? One option is for a separate team to be responsible for the API gateway. The drawback of this option is that it’s similar to SOA, where an Enterprise Service Bus (ESB) team was responsible for all ESB development. If a developer working on the mobile application needs access to a particular service, they must submit a request to the API gateway team and wait for them to expose the API. This kind of centralized bottleneck in the organization is counter to the philosophy of the microservice architecture, which promotes loosely-coupled autonomous teams.

When a team needs to change their API, they check in the changes to the source repository for the API gateway. In order to work well, the API gateway’s deployment pipeline must be fully automated. Otherwise, the client teams are often blocked waiting for the API gateway team to deploy the new version

Benefits and drawbacks of an API gateway
As you might expect, the API gateway pattern has both benefits and drawbacks.
Benefits of an API gateway
A major benefit of using an API gateway is that it encapsulates the internal structure of the application. Rather than having to invoke specific services, clients talk to the gateway. The API gateway provides each client with a client-specific API. This reduces the number of round trips between the client and application. It also simplifies the client code.
Drawbacks of an API gateway
The API gateway pattern also has some drawbacks. It’s yet another highly available component that must be developed, deployed, and managed. This creates the risk that the API gateway becomes a development bottleneck. Developers must update the API gateway in order to expose their services’ API. It’s important that the process for updating the API gateway is as lightweight as possible. Otherwise, developers are forced to wait in line in order to update the gateway.
Despite these drawbacks, for most real-world applications it makes sense to use an API gateway. If necessary, you can use the Backends for front ends patterns to enable the teams to develop and deploy their APIs independently

Comments

Post a Comment

Popular posts from this blog

Email Sending through O365 using OAuth Protocol

-
  Microsoft Office365 EWS servers have been extended to support authorization via the industry-standard OAuth 2.0 protocol. Using OAUTH protocol, user can do authentication by Microsoft Web OAuth instead of inputting user and password directly in application Microsoft / Office 365 OAuth + EWS We can use the OAuth authentication service provided by Azure Active Directory to enable our application to connect with IMAP, POP or SMTP protocols to access Exchange Online in Office 365. To use OAuth with our application we need to register application on Azure Active directory and other steps also we need to do to get the access token back. Below are the steps   To use Microsoft/Office365 OAUTH in your application, you must create an application in  https://portal.azure.com . Sign into the Azure portal using either a work or school account or a personal Microsoft account. If your account gives you access to more than one tenant, select your account in the top right corn
Read more

IISRESET vs App Pool Recycling ?

-
Image
 I think most IIS administrators know IISRESET command, and why they use it. One of possible reasons can be to restart IIS services to initialize web applications, or to apply some changes of applications & IIS settings .There’re just a few conditions those need your IISRESET command. In most situations, you don’t need this. I have a concern if you always run this command for applying any changes, or release system resource – memory – regularly, or frequently. Because it’s much more cost than what you really need to take – there’re side effects Recycling App Pool’ has been introduced from IIS6 in Windows2003. It’s designed to restart only application pools(=worker processes). It can be done in a command prompt(run ‘IISAPP /?’ in a command prompt for details), as well as in the IIS manager What IISRESET does? When you run IISRESET, many things will happen. In order to understand them, I think I need to show you how IIS looks like – about IIS core components. The below shows you role
Read more

Deploy .Net6.0 Web api with docker

-
Image
  What is Docker? Docker is a containerization platform, meaning that it enables you to package your applications into images and run them as “containers” on any platform that can run Docker. It negates the classic: “It works on my computer” argument as Docker images contain everything needed for the app to run. Are Containers the same as Virtual Machines? They are similar, but not the same. In short: Virtual Machines provide OS Level Virtualization Containers provide App Level Virtualization This concept is depicted below: Why Would You Use it? In short you would use Docker, (and hence containers), for the following reasons: Portability.  As containers are self- contained  they can run on any platform that runs Docker, making them easy to stand up and run on a wide variety of platforms. Scalability.  With the use of additional “orchestration” you can spin up multiple container instances to support increased load. Performance.  Containers generally perform better than their VM counterp
Read more