As often a gateway refers to a hardware in networking or communication, I would like to discuss the advantages of using a gateway a software prior to our services and APIs. Why I use and how I use it.
Introduction
Gateway is defined as "a piece of networking hardware or software which is used in telecommunication networks that allows data flow from one discrete network to another. Gateways are distinct from routers and switches in that they communicate using more than one protocol to connect multiple networks and can operate at any of the seven layers of the OSI model".[1] But in this article, instead of this broad definition, I am going to focus on API gateways which reside in front of the services or REST APIs and advantages of using such an architecture.
Background
When developing services and APIs, we often develop and publish the service only. After years of developing services at enterprise level, I have enjoyed use of gateways and its benefits and wanted to write an article to share my thoughts and experience on the subject. If we make a search on the internet for the advantages of using a gateway, you will surely find similar topics which are covered in this article as well. I am not re-inventing the wheel, so, sharing the same points is understandable, but I would like to tell them from my perspective.
Recently, I have been assigned to a new project, where old Windows Handheld terminals are replaced with newer Android ones. These old terminals are completely dependent on WCF and Web services because their operating system (Windows Mobile 6.5) and .NET Framework (CE 3.5) can't directly communicate with SAP. Also, there was another requirement that we should secure all services used within the company. I thought that this was a good opportunity to re-design the whole structure, but with minimum possible effort. However, the refactoring of WCF services is the topic of another article.
With the new design, I chose to use REST API to face Android clients with JWT authentication using .NET Core 3.1. The first challenge was SAP Connector DLLs were not written to support .NET Core, but .NET Framework instead. So there was no possible option to connect to SAP directly from a REST API written with .NET Core. My choice was to use .NET Core REST APIs as Transparent Proxies to communicate with SAP over existing WCF services. After writing REST API endpoints, I thought of using a Gateway to face devices first, instead of REST APIs which is the main context of this article.
Benefits of using a Gateway
Security
Our services are distributed over several servers which span through several locations which use different types of authentication. Some of them validate over SAP, while others are validated over Active Directory or use custom authentication. Use of a gateway allowed me to use it as a single point of authentication for all types instead of authentication/authorizing at each service. By using this architecture, we have prevented calling of services for unauthenticated/unauthorized calls at the gateway and also prevented unnecessary use of resources at the servers hosting services at the expense of using placing some logic at the gateway server. This approach also provided us great benefits of future improvements such as rate limiting, white/black listing,
Reusability
In our previous service architecture, we used to group functionality over module, such as SD services which connect and serve data from SAP's SD module or FI services which server from SAP's FI module. But with the new design, I wanted to serve over application instead of module. As the number of applications increase, we have faced the issue of using several modules within an application, but only some portion of module. Using a gateway which is fed from a routing table allowed us to re-group endpoints in applications perspective, including only necessary functions of existing services under a logical (application in this instance) name. For example, our new Customer Portal needs to communicate with SAP's FI module and SD module as well as to make some calls from MSSQL databases. But needless to say, the request of these uses does not cover all the functionalities of existing modules. Using a gateway allowed me to group the necessary existing service methods from different services into API endpoint set without doing additional work on existing services.
Maintainability
Our services grow and change all the time. The requirements of business change over time and these changes must be applied without causing a break at the service. In classical approach, we develop the updated version of service and cause a stop at the server while updating it. Also, there might be errors which break the process and require to return to a previous, working version. This is not much of a problem because we are using code versioning with TFS, but this incidence also cause stoppage of the service. But the use of a gateway allowed us to deploy several versions of a service at once and just switch to the next and previous versions by changing the record in the routing table with minimum stoppage time. Or re-route the API endpoint to another server on another location in case of a network failure.
Monitoring
Using a single point of data flow also allowed us to monitor performance metrics for all existing services and visualize bottlenecks or performance issues. Also logging errors provided us insight error without debugging the code, increasing the time to detect, locate and fix errors. When an end-user suffers from technical issues, it is a great thing to just check error logs and find the problem.
Load Balancing/Scalability
Gateways can also be integrated with a custom load balancer to distribute requests to several services providing the same functionality to share load when service servers become insufficient to serve incoming requests. It is also possible to balance the load in case of need, dynamically by updating the routing table (adding/removing service servers).
Caching
Although we have not used this approach, because we almost never have identical responses (as the nature of current processes, we almost never serve the same data, but different data in each request). But for another business where serving the same content over and over again in relatively short periods of time, it would be greatly beneficial to use caching at the gateway level to decrease the workload on service servers and improve the quality of service.
References and External Links
History
- 20th February, 2022: First version. Any updates will be listed here.
