Kong API Gateway | Nestjs

Wajiha Abid
4 min readJun 9, 2024

--

Kong gateway

What is Kong?

Kong is an open-source API gateway and it provides a comprehensive solution for managing APIs and microservices, offering a unified platform for developers to secure, monitor, and control their API ecosystem.

It also facilitates with authentication, authorization, rate limiting, and logging, while also offering features for traffic control and monitoring. Its scalability and performance make it suitable for handling high volumes of API traffic efficiently.

Modes of Kong:

There are 2 modes of kong:
1. Declarative: We provide the configuration through code. We put all the configuration in yml file.
2. Dynamic: We manage everything via Kong Admin API.

Why?

Our single application may used many different services. Either exposing all services, we can expose a single gateway through which an app can interact with the other services.
Consider the example of a party, think of Kong as a bouncer for your digital services, like a club entrance. In today’s digital world, many different programs and systems want to talk to each other, just like people wanting to enter a club. Kong stands at the entrance and checks who’s allowed in, making sure they’re not trying anything shady. It keeps track of how many people are coming in, so the club doesn’t get too crowded, and it also watches out for any troublemakers

Pre-Requisites:

  • Nest.js Background
  • Basic Knowledge of Docker

CONFIGURE KONG GATEWAY

Bind two Nest.js servers to a single IP and port.

For a example we have considered 2 Nest.js server running on different ports. Through kong gateway, we will access both server with one exposed port. On the basis of defined path, kong will redirect to your desired server. Lets start the configuration in 2 simple steps.

Step 1: Add server details to Kong.yml

                                                            ./kong/kong.yml

_format_version: "1.0"

services:
- name: auth-server # the name of service 1
url: http://172.24.160.1:3000 # the ip of host:port of server
routes:
- name: auth # list down the route names
paths:
- /auth
- name: user-server # name of service 2
url: http://172.24.160.1:3001
routes:
- name: users
paths:
- /users

This yml file is pretty similiar like docker-compose file. If you are aware of docker-compose then it’ll be alot easy for you to get grip on kong. First we define the version then list down the services you want.

How you define service:
- name of the service: could be anything you want.
- url: provide the IP and port on which your service is placed.
- routes: list down the names and paths as defined in your service.

Step 2: Write the docker-compose.yml

                                                         docker-compose.yml
version: '1.1'

services:
auth:
build:
context: auth
dockerfile: Dockerfile
target: development
command: npm run start
restart: unless-stopped
volumes:
- ./auth:/user/src/app
- /user/src/app/node_modules
networks:
- app-net
ports:
- "3000:3000"

user-server:
build:
context: user
dockerfile: Dockerfile
target: development
command: npm run start
restart: unless-stopped
volumes:
- ./user:/user/src/app2
- /user/src/app2/node_modules
networks:
- app-net
ports:
- "3001:3001"
kong:
image: kong
depends_on:
- auth
- user-server
volumes:
- "./kong:/usr/local/kong/declarative"
environment:
- KONG_DATABASE=off
- KONG_DECLARATIVE_CONFIG=/usr/local/kong/declarative/kong.yml
- KONG_PROXY_ACCESS_lOG=/dev/stdout
- KONG_ADMIN_ACCESS_LOG=/dev/stdout
- KONG_PROXY_ERROR_LOG=/dev/stderr
- KONG_ADMIN_ERROR_LOG=/dev/stderr
- KONG_LOG_LEVEL=debug
- KONG_PLUGINS=bundled
- KONG_ADMIN_LISTEN=0.0.0.0:8001, 0.0.0.0:8444 ssl
ports:
- "8000:8000/tcp"
- "127.0.0.1:7990:8001/tcp"
- "8443:8443/tcp"
- "127.0.0.1:8444:8444/tcp"
networks:
app-net:

In the above docker-compose, we have listed our 2 servers auth and user and exposed them to the port which is consumed by the kong. Then we have pulled the kong image and using it in declarative mode. As you can notice we have used one environment variable named “KONG_DECLARATIVE_CONFIG” and it takes the yml file path which we defined above.

In my case, I have used same docker-compose to start the services as well se kong but I have seen the scenarios where the microservices are located at different machines. And we used different machine IPs in the kong.yml and then start only kong via docker-compose.

Voila! you have connected your 2 microservice to a gateway, now you can access them through a common url. Consider the example below.

Conclusion:

For the architecture where you have multiple microservices and you want to maintain the uniformity or you dont want to expose your services directly so at such point Kong API Gateway is the best preference. This saves the development cost also because after this we dont need to write the custom gateway. For the code consider this github repo and stay tuned for the other features of Kong.

--

--