Kong API Gateway

A few points about the Kong API Gateway:

• It is fully Open Source
• Flexible Deployment
• Extensible via Plugins
• API GatewayMicro Gateway features i.e. it does not provide settings for lifecycle controls

Deployment Models:

Kong has 3 deployment models

DB-Less:

Need to configure it through a Yaml or JSON file and upload it based on the file, when it uploads this configuration it will be loaded in the memory of each Kong node.

With Data Damage:

The settings are all in a database shared by all nodes. One of the nodes will act as a control plane and pass the settings to Postgres which it passes to the other nodes.

Hybrid:

The hybrid deployment model is the model recommended by the Kong team, the idea is to have a control plane that only it will access the database, unlike the database deploy where all instances have access to the database. In this hybrid model, the other nodes will always receive the control-plane settings.

Services of Konga API Gateway:

A service is an entity that represents an upstream API or microservice. For example, a payment or registration microservice, etc.

Routes:

The routes are the URL paths that allow a service registered in our API Gateway to be accessed through the gateway. To register a route we have to go inside the registered service and go to the "Routes" option when we create a route we can define some settings one of them being the Host

Plugins:

Plugins are a piece of code that can be executed within the lifecycle of an HTTP request, both in the request and in the response, in other Gateways, this can be found as a policy but in Kong, it is called a plugin. Plugins can be configured in Routes, Services, Consumers and Globally, takes precedence for settings

this is the order of precedence, the lower the higher priority

Consumers:

It is who can consume your API, to test this part, I created two consumers, one that is a user and an app