Develop an API Gateway Using Tarantool (Part 1): The Setup
Learn about the theory behind developing an API Gateway using Tarantool.
Join the DZone community and get the full member experience.Join For Free
Adding another level of abstraction can solve many problems, but it doesn’t solve the problem of too many levels of abstraction. — Folk wisdom
In my previous articles, I’ve covered how to combine Tarantool with NGINX to develop APIs, how to use Tarantool modules, and how to write programs in Python 3 — skills that will allow you to solve application problems of any level of complexity.
All along, I have mentioned the benefits of a microservice and RESTful API architecture. However, I would also like to point out that this approach can cause certain issues, because as the number of microservices grows, the load increases, and providing interaction between the different parts of a distributed system can become challenging. Additionally, you will often have to deal with a large number of disparate information systems developed by different teams at different times, and thus problems of integration can become an issue. In other words, API services can be hard to modify as this may require changing other services and so on.
In short, we need something to orchestrate — an experienced “conductor” or a kind of “manager.” We need a single point of entry — which brings us to the API Gateway.
What Is an API Gateway?
An API Gateway is an interface that looks like a conventional object or service interface, but that allows our remaining objects to address the resources of our distributed system via a gateway that delivers their requests. What does this give us? First of all, it’s much easier to use one public address than tens or even hundreds of individual API addresses (if we have a very complex system). We also get a single authentication service with a unified user database.
In fact, authentication (and more generally, API security) is one of the main problems that is solved with an API Gateway. It’s not the only one, though: running a single "control room" makes it much easier to handle load balancing and traffic control, to set limits on the number of requests, and to perform other common tasks for the entire system. Basically, an API Gateway makes your system more flexible so that its internal structure is easier to change, which is particularly valuable if you have various teams engaged in developing microservices. It also seriously simplifies support for older API versions: you can cache data, or even merge responses from many services using synthetic (composite) requests, and so on.
What the Market Offers
API Gateways have become fashionable recently, and the market offers a few solutions to help implement an intelligent proxy server. First and foremost, there is the Amazon service AWS API Gateway. There is also an advanced NGINX solution and Lua-based tools like API Umbrella and Kong.
The Tarantool Approach
By the time you need an API Gateway, your distributed system will usually be quite complicated and probably heavily loaded. Tarantool is an in-memory, scalable, and fast non-relational database management system, but it’s not only a quick cache. It also has an advanced Lua-based application server that allows you to implement logic of any complexity. And its ecosystem features many free tools: a variety of connectors, the Queue module, the tarantool-authman module for creating an authentication server, etc.
Our API Gateway
The basis for our API Gateway will be the training project from our Tarantool Queues series. Behind our Gateway, we will place a number of microservices able to handle HTTP requests. Each microservice will offer a certain amount of resources via a RESTful API. We can have multiple instances of the same service running, and the Gateway will be able to choose a particular instance through a special service registry. Data on services and the APIs is stored in a special controller that collects imported routes (permitted requests). In addition, the gateway must be allowed to do synthetic (composite) requests, which is quite logical if there is only a single entry point for all of the services.
So let’s define the requirements for our API Gateway. It should:
- Be horizontally scalable, with no application states.
- Combine queries and call microservices asynchronously.
- Limit the number of requests per unit time.
- Verify token authenticity (our API Gateway authenticates whereas the microservices behind it authorize when you try to access their resources).
- Automatically import exposed resources from microservices.
- Modify (mutate) microservices’ responses.
This article contained the theory, but in part two, we will switch to the practice, transforming our authentication service into a full-fledged API Gateway. Our first step will be to implement request processing as well as the service-routing registry.
Opinions expressed by DZone contributors are their own.