Welcome! You are about to start on a journey about and how to setup kong as an API Gateway for your infrastructure. In this first chapter, you are going to learn what and why we need API Gateway. By the end of this chapter you are going know why API Gateway is important in Microservices Architecture.

Table of Content

• Api Gateway Series
• What is API Gateway
• Why need API Gateway
• API Gateway
• API Gateway Solution

You may have heard the terms "API Gateways" or maybe the popular api gateway solution like Tyk, Apigee, Kong or Amazon AWS API Gateway. These come up a lot nowadays because a lot of company started adopting or migrating towards microservices architecture.

What is API Gateway?

API Gateway is middleware that sit between your client application and your server side application so all incoming request from client must be done through API Gateway. When you think about it, isn't API Gatway exactly like how reverse proxy works? Yes you could say API Gateway has some similiarity. Reverse Proxy is responsible to routing request from client to right server but API Gateway is operating at different layer, API Gateway is responsible to routing request from client to right application / services on the server. API Gateway also have other benefit that will we discussed later.

Why need API Gateway?

Before answering this question, let's take a look at this architecture.

This is represent how most monolith architecture works, you have client application it can be web or mobile and then you have one server side application serve as REST API containing all business logic and connected to database. These would be fine untill you introduce another REST API.

Now let's take a look another architecture.

Direct Client‑to‑Microservice Communication

In theory, a client could make requests to each of the microservices directly. Unfortunately, there are challenges and limitations with this option.

Inefficiency

When you have more than one REST API, the client start getting confused because now they need to know, if they need fetch list of shopping cart they need to request it from Shopping Cart Services, and repeat the same step for another functionality. This would make client application need to execute multiple HTTP request to render certain page and also this approach make client application much more complex.

Protocol

If you are working with REST API this would be fine untill you introduce server side application that use protocols that are not web‑friendly. Some might use Thrift binary RPC while another service might use the gRPC. Neither protocol is particularly web‑friendly.

Refactoring

Good software is always evolve. Over time we might want to change how the system is partitioned into services. For example, we might merge two services into one or split a service into two or more services. If clients communicate directly with each services, then performing this kind of refactoring can be extremely difficult.

API Gateway

To solve number of problem that might be happen using direct communication, we need a gateway.

Now client application is communicating through API Gateway, we gain several benefit.

Decoupling

By communicating through API Gateway, API gateways enable us to route based on path, hostname, headers, and other key information enabling us to decouple API used by client from actual services. With this renaming, reorganizing and splitting services is much easier especially if were dealing with client that we have no control over.

Performance

Using API Gateway we gain better performance. Because instead client join data manually from multiple services, data that required by client can be aggregated by the API Gateway itself.

Translation

When client request data to server through API Gateway. API Gateway will done something call protocol translation, so whatever protocol used by server (Thrift, gRPC, AMQP) it will endup translated before send to client, so client only dealing with understandable response.

Centralized

Authentication Logging, Rate Limiting, CORS and many other things can easily configured at API Gateway level so underlying service doesn't need to implement their own way.

Existing API Gateway Solution

Kong

Kong is an API gateway that is build on top of (NGINX). It has 2 type of product that is open source and enterprise. All essential features is available with the open-source version, while features like the Admin UI, Security, and developer portal only available on enterprise version.

Tyk.io

Simillar with Kong, Tyk is also has open source version. Tyk is more of a batteries included API Gateway. Authentication schemes like OIDC, OAuth2, Bearer Token, Basic Auth, Mutual TLS, HMAC are all supported out of the box without requiring plugins. It also has support for XML->JSON, JSON->XML, JSON Schema Validation.

Apigee

Oldest API Gateway listed here is Apigee. Founded in 2004 and acquired by Google in 2016. Apigee is not open source and is built on enterprise Java. Apigee focus was to turn legacy monoliths into APIs that can be consumed by third parties.

Amazon AWS API Gateway

Amazon as the biggest cloud vendor provide AWS API Gateway. AWS API Gateway is fully managed and can be deployed with a few clicks in the AWS portal.

Api Gateway series

if you like to know other series please check out below:

• Introduction (This Articles)
• Setup Kong