Modern software development applications are built based on the microservices architectural style i.e. by dividing the functionality of complex web applications in smaller, fine-grained web services that can be deployed and scaled independently. Microservices architectures constitute the modern evolution of traditional service-oriented architectures that break down complex applications in loosely coupled services. Microservices rely on lightweight protocols and facilitate automation in testing and deployment processes, including Continuous Integration and Continuous Deployment (CI/CD).
From a developers’ perspective, interaction with microservices is based on conventional APIs (Application Programming Interfaces). Experience shows that it is not always practical for developers to know the low-level details of all the microservices that comprise a modern web application. Hence, the idea of decoupling developers from the low-level functionalities has emerged and over the years gained momentum. In this direction the API gateway pattern has been introduced and implemented by major cloud services providers like Amazon and Netflix. In a nutshell, an API gateway mediates between a client and the collection of backend services (i.e. microservices) to provide support for handling common tasks notably tasks that are associated with the use of different microservices.
The motivation behind the API Gateway pattern lies in the different granularities of the services used by a client application and the services that are available as part of a microservices architecture. Microservices tend to be associated with fine-grained APIs, which requires developers to understand, invoke and interact with many different services. For example, in a typical product/catalogue service, a developer would have to invoke multiple microservices to access the list of available products, rather than invoking a single API. It will have to invoke authentication and authorization services, on top of the business logics of the products’ listing.
Another motivation behind the use of the API gateway patterns stems from the fact that different clients need to access different pieces of data at various granularities. For instance, in Netflix, users are presenting with different pieces and granularities of data depending on the device they use (e.g., TV, Desktop Computer, SmartPhone, Tablets, Set-Top Boxes) to access the service. Likewise, the network performance required for different clients varies. As a prominent example, clients accessing the service from a mobile network must cope with less bandwidth and higher latency, when compared to conventional wireline network.
At the server-side, there is a need for coping with different numbers of service instances and their location. Specifically, service instances and their locations can change dynamically. Moreover, from time to time, service providers tend to change the partitioning and granularity of the various microservices, as part of their continuous efforts to refactor their services and to improve their performance.
Hence, there are many good reasons for decoupling individual microservices from the APIs that should be exposed and offered to client applications. API gateways provide the means for implementing this decoupling through consolidating many low-level functionalities in fewer higher-level API calls. Specifically, an API gateway integrates within a single API calls multiple common tasks such as authentication, rate limiting, logging, extraction of statistics, traffic management, cross-origin resource sharing (CORS), and API versioning management. It essentially provides a unified entry point for external consumers of back-end services, which hides the complexity of the underlying microservices.
API Gateways provide significant benefits for developers: They facilitate the tasks of creating, publishing, maintaining, monitoring, and securing APIs according to the developers’ needs. They help developers to access data, business logic and other functionalities of their microservices. State of the art gateways provide support for containerized workloads and serverless applications, which is a key to supporting modern development and deployment architectures. Furthermore, API gateways support both RESTful APIs and WebSocket APIs i.e. they provide flexibility in the type of applications that can be supported through the API gateway pattern. RESTful APIs support serverless workloads and http backend call based on HTTP APIs i.e. they are ideal for proxy functionalities. On the other hand, WebSocket APIs are preferable for building real-time two-way communication applications (e.g., chat and streaming applications). They provide the means for handling continuous conversations and message exchanges between the client and the service back-end.
From a technical perspective, API gateways help reducing the number of requests and responses between clients and back-end servers. For instance, clients can retrieve data from multiple services with a single round-trip request. This technical benefit translates to less message overhead, bandwidth savings, and improved user experience. Moreover, an API gateway obviates the need for clients to know how the server-side is partitioned into microservices. It also facilitates location agnostic calls, as there is no need for the client to know the actual location of service instances. Most importantly, an API gateway is usually optimizing API invocations in terms of granularity, performance, and latency, which improves the efficiency of the application development process.
Another merit of API Gateways is that they are provided as fully managed services. Application and service developers need not worry about setting them up and maintaining them. Rather they can use them like any other pay-as-you-go cloud service. Specifically, API gateway users pay according to the number of API calls that they invoke and according to the amount of data transferred from the gateway to the client. A typical price involves few dollars for some millions of requests to the gateway. Moreover, several cloud providers reduce API costs as usage grows, towards offering improved cost-benefit for high-usage of the APIs.
Overall, there are some very good reasons for considering the API gateway pattern when architecting and programming your microservices applications. Nowadays, developers can benefit from managed services provided by the API gateways of giant vendors. However, it is also possible to implement this pattern as part of your application infrastructure. In several cases (e.g., mobile applications) the development and use of an API gateway infrastructure is a key success factor for the application development process. It is probably time that you understand how to benefit from available API gateways, as well as how to build your own API gateway infrastructure.
Embedded Finance: Enabling New Customer Facing Intelligence
API Management: A Powerful Tool for Creating Business Value
Looking for reasons for Managing your own APIs?
Effective KPI Framework for CIOs: 7 recommendations
The Potential of Big Data in the Telecom Infrastructure Industry
Trading Data as NFTs: The basics you need to know
Active (Machine) Learning: Leveraging Human Experience to Improve AI
Digital Platforms for a Circular Economy
Neuro-Symbolic Learning Explained
AI Regulatory Initiatives Around the World: An Overview
We're here to help!
No obligation quotes in 48 hours. Teams setup within 2 weeks.
If you are a Service Provider looking to register, please fill out this Information Request and someone will get in touch.
Outsource with Confidence to high quality Service Providers.
If you are a Service Provider looking to register, please fill out
this Information Request and someone will get in
Enter your email id and we'll send a link to reset your password to the address
we have for your account.
The IT Exchange service provider network is exclusive and by-invite. There is
no cost to get on-board;
if you are competent in your areas of focus, then you are welcome. As a part of this exclusive