Forem: Adisakshya Chauhan

Setting up an API Gateway for your Microservices

Adisakshya Chauhan — Sun, 17 Jul 2022 09:13:26 +0000

In the previous article from the API Gateway 101 Series we saw an Introduction to API Gateway, understanding the basic know-how. Now it’s time to see an API gateway in action in front of multiple microservices.

We’ll be spinning up multiple mock microservices within a private network (docker network) making them inaccessible from the host. The API gateway will be accessible from the host and all the microservices will be attached to the gateway. Thus any client request needs to go through the gateway first before being served by the actual microservice in the backend.

Prerequisites

We’ll be deploying the API gateway and the mock microservices using Docker. If you’re not familiar with Docker & Docker Compose then here is a quick link to understand the basics - Docker Docs.

For exploring and utilizing the Kong Admin API we'll be using Postman Collections.

Postman is an API Client that assists to create, share, test and documenting APIs.
Postman collections are basically a group of saved API requests that are executable.

You’ll see that I’ve organized the postman collection for this series in folders making it easy for you to explore saved APIs section-wise. Postman isn’t necessary for this series, you can easily replicate the saved APIs into your favourite API client.

NOTE: I’m using Docker installed on a windows machine. In this article where ever I mention ‘192.168.99.100’, it refers to the ‘docker-machine ip’.

Cool, now that once Docker, Docker Compose & Postman are installed, we can move forward to get started. Let’s now get our hands dirty by spinning up some mock microservices and setting up an API Gateway in front of them.

Spinning up mock microservices

The source code for the mock microservices created for this article can be found on my GitHub repository - adisakshya/api-gateway

To get started let’s clone the git repository -

git clone https://github.com/adisakshya/api-gateway
cd api-gateway/single-node-kong-gateway

Source code for each mock microservice lives in the respective directory named after them. Some services are defined directly in the docker-compose file. All the microservices and the API gateway can be started at once using the following command -

docker-compose up -d

This will start the respective docker containers in the background of your terminal (aka docker detached mode). You can check the list of containers that are up using the following command -

docker ps -a

Since we’re running docker containers in the detached mode we’ll not be able to see any logs. But If you want to see logs of a specific container you can use the following command -

docker container logs '<<CONTAINER_ID>>'

The IP for the internal docker gateway is 172.18.0.1, to get the IP for a particular docker container you can use the following command -

docker inspect '<<CONTAINER_ID>>' | tail -n 20

I’ve used the tail command to see the IP address of the docker container, which is found towards the end of the response from the docker inspect command.

We’ll need the IPs of the docker containers to attach these microservices to our Kong API gateway. By now you’ll have the following containers up and running -

Container Name	IP (Docker Network)	IP (Host Network)
Konga (Admin GUI)	172.19.0.2	192.168.99.100:1337
Kong	172.18.0.9	192.168.99.100:8000-8001
Kong Database	172.18.0.3	192.168.99.100:5432
Nginx Web Server	172.18.0.6	Not accessible
Apache Server	172.18.0.2	Not accessible
HTTPBin	172.18.0.5	Not accessible
Application Server A	172.18.0.7	Not accessible
Application Server B	172.18.0.4	Not accessible

Kong Gateway APIs

Kong can be administered with an internal RESTful API called the Admin API. This API provides full control over the kong gateway.

8001 is the default port for HTTP traffic to the Admin API.
8444 is the default port for HTTPS traffic to the Admin API.

Apart from the Admin API, we have another API using which the API consumers can consume the services. This API needs to be exposed to the world in order for the services to be accessible.

8000 is the default port for HTTP traffic from Consumers.
8443 is the default port for HTTPS traffic from Consumers.

The traffic from consumers on 8000/8443 is forwarded to the corresponding service based upon the defined routes.

Accessing the Admin GUI (Konga)

The admin GUI can be found at 192.168.99.100:1337. Once you register yourself as an admin you'll be prompted to specify the kong admin URL using which the Admin GUI can create objects like services/routes etc on the kong node.

The Kong Admin API is found at 192.168.99.100:8001. Once the Admin GUI is connected to the Admin API you’ll be directed to the main dashboard -

Interacting with the Kong Admin API

I’ve created a Postman collection containing the requests that can be made to the Kong APIs for administrating and accessing services from the gateway.

The Admin API provides a ‘/status’ route that can be used to check the status of a Kong node.

The Admin API provides you with complete control over the Kong Node so there’s a lot you can do with this API like attaching/detaching backend services, creating/removing consumers, creating passwords for users and much more.

To get the full list of routes provided by the Admin API you can call the ‘/endpoint’ route. I’ve included a few requests in the postman collection for you to explore the Admin API.

Registering the microservices with the API gateway

Having played with the Admin API now let’s attach our already running backend microservices with the API gateway.

Every microservice will have a service object corresponding to it on the API gateway that is identified by the service name, hostname (or IP address) and a port number.
Every service will have defined route(s) which can be called by the end-users.
The request to any route is proxied to the corresponding backend microservice and the generated response is returned back to the end-user by the API gateway.

To create a service object for a backend microservice, we can send a POST request to the Admin API on the ‘/services’ route with the service name, hostname and port number (default 80).

Having created a service object for all our microservices we can get a list of available services on the API gateway using the Admin API.

Having defined the service objects now we need to create the routes to which the API consumers can forward their requests. To create a route object for a gateway service, we can send a POST request to the Admin API on the ‘/routes’ route with the route name, route path and list of allowed methods on that path.

Having created route objects for all our gateway services we can get a list of all available routes using the Admin API.

Utilizing the microservices from the API gateway

All the routes defined on the gateway are reachable from port 8000. Let’s hit the routes we’ve created and analyze the response. We’re running a raw Nginx Web Server behind the route ‘/nginx’, let’s hit it first using the API -

As expected the response returned is the default Nginx welcome page, this means that the backend Nginx web service running on 172.18.0.6 (inside docker network) is now accessible on the host via the API gateway. Now let’s try hitting the HTTPBin service -

The purpose of using the HTTPBin service was to analyze the returned response in detail. Focus on the fields named ‘X-Forwarded-Host’, ‘X-Forwarded-Path’ and ‘X-Forwarded-Prefix’, these fields are often referred to as X-Forwarded-For (XFF) HTTP header fields.

XFF fields are used for identifying the originating IP address of the consumer who is connecting to the service. There can be more details like UserId and Username of the consumer as part of XFF which can be utilized by the backend microservices. We’ll be exploring them in detail in upcoming articles.

Next Steps

As you might have noticed already that all the services that we’ve created are open to access for anyone on the host. In the next article, we’ll understand some key concepts about authentication and authorization to secure our backend services. We’ll see how we can restrict access to a particular backend service on the user level.

See you there!

Contribution

Enjoyed the article, found it useful or learned something new? Consider sharing it so more people can benefit from it! Also, feel free to @ me on Twitter with your opinions.

Found a mistake? Feel free to mention it in comments or at GitHub issues or fix it using a PR at adisakshya/weblog.

Introduction to API Gateway

Adisakshya Chauhan — Tue, 01 Feb 2022 18:55:45 +0000

Let’s say we are building an application that uses the microservices architecture. These types of applications provide API delivering a specific use case. Additionally, the number of running service instances or the number of services in an application itself can change, which should be hidden from clients.

So how do the clients of Microservices-based applications access the individual services? The client application would need to interact with multiple different services to get the required information for the user and any update in a service should be hidden from clients.

This is where the concept of API Gateway comes into the picture. It follows the literal meaning of a “Gateway” - the place which you must go through to get to somewhere else.

The API Gateway acts as a single entry point to the available backend services in an application for all the clients. It can also implement security, e.g. verify that the client is authorized to perform the request. Just like a security guard standing in front of the gateway and verifying if you are allowed to go beyond the gateway.

In this API Gateway 101 series, we’ll understand what these gateways are all about and get our hands dirty by setting up an API Gateway in front of an application that uses the microservices architecture deployed on Kubernetes. But one step at a time.

What is an API?

Firstly we need to understand what exactly an API is?

Application Programming Interface (API) provides a blueprint that specifies how application services in a software system should interact with each other. It acts as a bridge between different services and abstracts away the underlying complexity to present it as a well-defined product.

Cool, now let’s get started and understand -

What is an API Gateway?
What is the difference between API Gateway, Load Balancer and Reverse Proxy?
What is Kong?
What is the use of an API Gateway in a microservices environment?

What is an API Gateway?

At the most basic level, an API follows a request-response cycle i.e., the API service accepts a remote request and returns a response. But this isn’t that simple, let’s think about various concerns when we host large-scale API -

We want to protect our API services from overuse and abuse, so we should use an authentication service and rate-limiting etc.
We want to understand how people use our APIs, so we’d like added analytics and monitoring tools.
Over time we’ll add some new API services and retire others, but our clients will still want to find all our services in the same place.

The challenge is to provide the clients with a simple & dependable interface for enabling them to interact with our system and manage remote requests in a centralized manner.

An API gateway is an API management tool that sits in front of the backend API services and acts as a single entry point for all clients wanting to consume the services.

The gateway intercepts all the incoming remote requests and can apply a variety of necessary checks and functions.

API Gateway vs Load Balancer vs Reverse Proxy

At this point, an API gateway might sound pretty similar to a load balancer and reverse proxy. These applications sit between the clients and backend servers, accepting remote requests from the former and delivering responses from the latter.

To understand the difference, let’s explore when and why they’re typically used -

Load Balancer

Load balancing helps prevent the overloading of individual systems & prevent failure due to the same. A load balancer offers the ability to distribute incoming remote requests across multiple backend services.

Say, we are running 5 instances of a backend service behind the load balancer. The incoming requests will be distributed between these 5 servers following the load balancing strategy like round-robin, least utilized etc. If any of these 5 servers fail due to any reason then the load balancer would distribute the incoming requests to the remaining operational backend services.

Reverse Proxy

A Reverse Proxy acts as a mediator between the client and one or more backend services.

It can rewrite the URLs, so the client will not know who is sitting behind the reverse proxy. Its responsibility is to forward the remote request to the appropriate backend service that can fulfil it.

A typical reverse proxy can be used for -

Load Balancing: it offers the ability to distribute incoming requests across multiple backend servers.
Caching: content is often kept in a place called proxy cache. So for recurring requests, it can answer autonomously in less time.
SSL Encryption: it can be configured to decrypt all incoming requests and encrypt all outgoing responses.

API Gateway

We can think of the API Gateway as a superset of a Reverse Proxy.

The gateway hides the backend architecture from the clients. It addresses some common utilities like -

Authentication and Authorization: It can control who can request what
- Example - It offers the possibility to control the access to specific backend services based upon the plans that the API consumer have purchased.
IP Whitelisting: It can grant the ability to use the API services only to specific IP addresses
Rate Limiting, Throttling, and Quota: A limit can be set based on how many requests the backend servers can handle for a certain unit of time.
- Looking at the commercial aspect, it offers the possibility to control the traffic that API consumers are using based on the plan they’ve purchased
Logging, Tracing, Correlation: It can gather all the logs for each specific remote request.

Differences at a glance -

Function	Load Balancer	Reverse Proxy	API Gateway
Balance incoming requests	✅	✅	✅
URL Rewrite		✅	✅
Caching		✅	✅
Prevention from Attack			✅
Protocol Translation			✅
Authentication			✅
IP Whitelisting			✅
Rate Limiting, Quota			✅
Logging			✅
Tracing			✅
Health Checking			✅
Dynamic Config Updates			✅

What is Kong?

Kong Gateway is one of the most popular open-source API gateways. It securely manages the communication between clients & backend services via an API.

Kong sits in front of backend services and extends these APIs using Plugins to provide extra utilities like authentication, rate-limiting etc

A typical Kong API Gateway setup looks something like this -

Once the architecture is deployed and running, every remote request to the backend services will hit kong first thus becoming the entry point for any API request.

If you want to deep dive into working of Kong then you can refer to this - https://konghq.com/faqs/

What is the use of an API Gateway in a microservices environment?

In a microservices architecture, each microservice exposes a set of endpoints with specific functionalities.

Client applications usually want to consume functionality from more than one microservice. If there is a direct Client‑to‑Microservice Communication, then the client application would need to handle multiple calls to the backend microservice endpoints. When the client application is linked with the internal endpoints then evolving the microservices would mean updating the client application too. But ideally updating internal APIs should have minimal impact on the client application.

This is where the API Gateway comes to the rescue, it encapsulates the backend services architecture and provides an API that can be customized for each client application.

Next Steps

We’ll get our hands dirty in the next article where we’ll

Spin several microservices
Setup a Kong API Gateway in front of the microservices
Access the created services them using the gateway

See you there!

Contribution

Enjoyed the article, found it useful or learned something new? Consider sharing it so more people can benefit from it! Also, feel free to @ me on Twitter with your opinions.

Found a mistake? Feel free to mention it in comments or at GitHub Issues.

Thanks for reading!

Extension Pack for VSCode & Code Server

Adisakshya Chauhan — Fri, 30 Jul 2021 18:54:31 +0000

Hello DEVs, its my first post here!

In this article, we'll create a common extension pack for VS Code and code-server, explore the involved compatibility issue and Travis Workspaces. Finally, we'll build a CI/CD pipeline to publish our extension pack to a GitHub release.

Extension packs in VS Code are useful when we want to bundle and install a set of extensions together. It also provides us with a way to share and organize our favourite extensions.

Prerequisites

If you've never built an extension before, you'll need VS Code and NodeJS installed.

We'll create a versioned extension pack, so a git repository is needed where we can maintain the source code of our extension pack. Also on this repository, a CI/CD pipeline will be built later in the article. The extension pack will be published on the repository release page by the pipeline, from where anyone can install and use it.

The source code of the extension pack created for this article can be found at my GitHub repository - adisakshya/extension-pack.

Once NodeJS is installed, the git repository is created and cloned we can move forward to get started.

Installing Yeoman & Code Generator

To get started creating an extension pack,

We'll need to install the Yeoman scaffolding CLI tools as well as the generator.

Yeoman can be installed using the following command -

npm install -g yo

Then we can install the generator tools like so -

npm install -g generator-code

Generating a New Extension Project

With the correct tools installed, we are now ready to generate a new extension pack project. This is pretty easy as all of the scaffolding is already provided. So all we have to do is add to the list of extensions to be included.

We can start this process by running the following command in our git project directory (extension-pack) -

yo code

Understanding the generated code

The following directory structure will be created inside the project directory by the generator -

+-- .vscode
|   +-- launch.json
+-- .vscodeignore
+-- CHANGELOG.md
+-- package.json
+-- README.md
+-- vsc-extension-quickstart.md

Let’s explore everything in it -

vscode/launch.json is a file used to configure the debugger in VS Code.
The .vscodeignore file excludes some files from being included in your extension's package.
Record of all notable changes made to the project is maintained in CHANGELOG.md.
README.md is the project readme file, it'll also be used in the extension packs page in the VS Code marketplace.
Every VS Code extension needs a manifest file package.json at the root of the project directory structure. Most of the time we'll find ourselves tweaking the manifest file. A great reference can be found here at VS Code API Reference.
vsc-extension-quickstart.md feature some quick-start tips.

Make it yours

Cool, so now that we understand (hopefully 😅) what everything means! We can move forward to update the package.json manifest to customize our extension pack. The field names are quite clear with their meaning.

First things first - Let’s name, describe and version our package.

"name": "adisakshya-extension-pack",
"displayName": "adisakshya-extension-pack",
"description": "Adisakshya's extension-pack for VS Code & Code Server",
"version": "1.0.0"

Second things second - Update the list of extensions in our pack.

The extensionPack field is a list of extension-ids. The ID of the extension can be obtained from VS Code Marketplace.

"extensionPack": [
    "cssho.vscode-svgviewer",
    "docsmsft.docs-markdown",
    "eamodio.gitlens",
    "EditorConfig.EditorConfig",
    "esbenp.prettier-vscode",
    "formulahendry.code-runner",
    "GitHub.github-vscode-theme",
    "GrapeCity.gc-excelviewer",
    "humao.rest-client",
    "johnpapa.vscode-peacock",
    "ms-azuretools.vscode-docker",
    "ms-python.python",
    "ms-python.vscode-pylance",
    "ms-vscode-remote.vscode-remote-extensionpack",
    "ms-vscode.cpptools",
    "ms-vscode.vscode-typescript-next",
    "ritwickdey.LiveServer",
    "VisualStudioExptTeam.vscodeintellicode",
    "vscode-icons-team.vscode-icons",
    "vsls-contrib.codetour"
]

Third things third - Specify an icon

We can specify an icon for our extension pack by placing our icon-file.png in our project directory. Its path has to be mentioned in the package.json manifest like -

"icon": "path/to/icon-file.png"

Now that we've specified what extensions need to be included and other associated information. We can pack the extensions in a file that can be used to install the extension pack on VS Code and code-server.

Packing the extensions

Visual Studio Code Extensions (aka vsce) is a command-line tool for packing, publishing and managing VS Code extensions. It can be installed using the following command -

npm install --global vsce

We'll choose to pack our extension into a VSIX file, using which people who wish to use the same pack can install it.

We can package the extensions in a VSIX file using the following command in our project directory -

vsce package

For users who receive the VSIX file, they can install the extension pack on VS Code and code-server like so -

# VS Code
code --install-extension adisakshya-extension-pack-1.0.0.vsix

# Code Server
code-server --install-extension adisakshya-extension-pack-1.0.0.vsix

A handy NPM script can be included in package.json -

"scripts": {
    "pack": "vsce package"
}

This can be used as an npm run pack or yarn run pack in CI.

Understanding the VS Code compatibility

This is one of the most important things we (or at least I) unconsciously ignored.

I packed the extensions in a VSIX file and tried installing it on my local system with VS Code installed. Great, it worked as expected.

I took the same VSIX file and tried installing it on a code-server setup in Windows Subsystem for Linux (WSL). And... saw the below message -

Okay... so it said - Unable to install extension 'adisakshya-extension-pack' as it is not compatible with VS Code '1.53.2'. I figured out that it had something to do with the version of VS Code for which the extension pack was created.

One thing that looked SUS was the engines.vscode field inside package.json, which was the only thing I left as default. I went through the VS Code Extension API Reference to find out what this field really is and what I found was -

When authoring an extension, you will need to describe what is the extension's compatibility to Visual Studio Code itself. — API Reference

The engines.vscode field is an object that contains a key matching the versions of VS Code that the extension or extension pack is compatible with. If I'm generating the scaffolding code on my system then this field is set to the version of VS Code I'm using by default.

"engines": {
    "vscode": "^1.56.0"
}

I was using the 1.56.0 version of VS Code and generated the VSIX file with this configuration. 1.53.0 was the version of VS Code associated with the code-server release that I was using.

Okay, the extension pack that I created was meant to be compatible with version 1.56.0 and above. While the code-server was using 1.53.0 — this was the reason for that incompatibility message!

I updated the engines.vscode field to ^1.53.0 to make it work, but still, the installation failed on code-server as some extensions inside the pack were not compatible with this version of VS Code. So next possible solution was to upgrade the code-server.

I installed the 3.10.2 version of code-server which used VS Code 1.56.0 and tried installing my extension pack with engines.vscode field set to 1.56.0. Great, it worked!

So,

Before packing our extension we must ensure that we’ve mentioned the engines.vscode field correctly according to our use.

To find out what version of VS Code engine is our code-server setup using, see the Welcome Screen -

Publishing the extension pack

We'll be publishing the VSIX file of our extension pack to a GitHub Release using Travis CI. Let’s define our expectations — The CI workflow should do the following -

Pack the extensions in a VSIX file
Publish the VSIX file to GitHub release
We should be able to download the latest release of the extension pack (using a single terminal command so that we don’t have to install it from the marketplace every time and can use this command in automation scripts)

While writing the Travis YML file I came across a much-awaited (at least for me) beta feature - Workspaces.

Workspaces allow jobs within a build to share files. They are useful when you want to use build artefacts from a previous job. — Travis Workspaces Docs

Cool, this means we can have two stages where the first stage would pack the extensions in the VSIX file and upload it to a workspace. Then the second stage would use the same workspace to get the VSIX file and publish it to a GitHub release.

Now once released how we’ll use our extension pack’s VSIX file?

VSIX files uploaded to a GitHub release can be downloaded using the curl command. Then we can use the code [or code-server] --install-extension command to install the extension pack. If you use an automation script to set up VS Code or code-server then this way you can write a single line in the script to install the extension pack as well.

Cool, now we’ve defined what each stage in the pipeline should do -

✅ What do we release?

✅ How do we release?

✅ How are we using, what we are releasing?

So, let’s write the Travis CI configuration .travis.yml -

# Language and Node Engine
language: node_js
node_js: 12

# Environment Variables
env:
  global:
    - PACK_NAME=adisakshya-extension-pack
    - VERSION=$(node assets/version.js -p)

# Jobs
jobs:
  include:
    # STAGE 1
    - stage: build
      name: "Build"
      install:
        # Install VSCE
        - npm install --global vsce
      script:
        # Pack extensions
        - npm run pack
      # Create a workspace
      workspaces:
        create:
          name: ws1
          # Upload artifact to the workspace
          paths:
            - ${PACK_NAME}-${VERSION}.vsix
    # STAGE 2
    - stage: GitHub Release
      name: "Publish VSIX file on GitHub Release"
      # Use an existing workspace
      workspaces:
        use: ws1
      install: skip
      script: skip
      # Publish VSIX file to GitHub release
      deploy:
        provider: releases
        api_key: ${GITHUB_SECURE_TOKEN} # The GitHub Access Token
        name: ${VERSION} # Name of release is set as the version of extension pack
        file: ${PACK_NAME}-${VERSION}.vsix # Attach VSIX file with the release
        skip_cleanup: true
        on:
          tags: true

Let's push all our changes to the GitHub repository of the project and check the build stages status.

On success, the VSIX file will be published to a GitHub release.

The following command will download and install the VSIX file from the latest GitHub release -

curl https://github.com/adisakshya/extension-pack/releases/latest/download/adisakshya-extension-pack.vsix -O -L && \
code --install-extension adisakshya-extension-pack.vsix

The format of the URL to download VSIX file from a specific GitHub release is -

https://github.com/adisakshya/extension-pack/releases/download/<GIT_TAG>/adisakshya-extension-pack.vsix

Voila!

Let’s use what we’ve created!

Contribution

Enjoyed the article, found it useful or learned something new? Consider sharing it so more people can benefit from it! Also, feel free to @ me on Twitter with your opinions.

Found a mistake? Feel free to mention it in comments or at GitHub Issues.

Thanks for reading!