This content originally appeared on DEV Community and was authored by Decentro
API development has moved from a single stack monolithic architecture to the majestic microservices architecture.
This requires a gateway server that should manage redirection, proxying and security over multiple requests. This means our old faithful NGINX has become a little outdated. (Let’s not even talk about Apache HTTP Server here!)
Even if you run a monolithic application, The API Gateway is still a good pick. Apart from proxying, there are many other benefits.
The API Gateways should give us the developer the ability to:
- Scale: As you grow, so should your application
- Provide security: Applying SSL is just scratching the surface
- Have a GUI: This would make life 10 times easier
- Be Intuitive: Should be self explanatory
_“But what does it do?”
_
You may ask. Good question.
Suppose we have an API stack with multiple APIs spanning over a bunch of microservices. Let’s look at the diagram:
Here you can see the API Gateway being the lord and the savior for the application instances running behind it. It proxies the requests to the requisite application instance (as a reverse proxy). Now your endpoint can be independent of the microservice it caters to.
So if you want to have multiple endpoints (e.g., /docs, /documents, /documentation) connected to the same application, you can. Just reverse proxy it, baby!
Farewell, NGINX!
Here at Decentro, we used to work with NGINX as our reverse proxy server. But we grew out of it. We had to log in to our instance to reload NGINX via CLI and had to learn to manage configurations when using NGINX. It didn’t have consumer-level handling for API management.
We needed something extra. After logging our heads together for quick brainstorming and crossing the Is’ & Ts’ on the Pros/Cons list, we found the one!
Dhumm… Dhumm… Dhumm…
Did you feel it?
Here comes KONG!
Source: Github
As is evident from the image above, Kong provides a lot of features out of the box. No recompilation. No command-line configuration. No extra cost.
Kong comes with its own RESTful Admin APIs. It is built on top of OpenResty (an extension of NGINX) and LuaJIT. These provide access to all kinds of configurations that can be made available. We have done another addition on top of it by adding the Konga dashboard to manage Kong via a GUI.
Kong API Gateway Structure
The API structure in Kong is pretty simple:
- Services – The logical representation of your microservice or monolithic application
- Routes – The logical representation of endpoints that are accessible within the service.
- Consumers – The clients that are going to be using the services.
- Plugins – This is where the magic happens. Plugins can be applied to either of the above entities mentioned. So let’s talk about an example.
I have a microservice that takes care of sending emails. I will declare a Service with the name “emails” (Pretty innovative.. I know). This will contain the details of the application server, which it will reverse proxy for.
Now let’s make Routes for this service. So we have two kinds of emails to be sent.
- Transactional – Sent by the API
- Marketing – Sent by the marketing department to let the clients know about the new features of our awesome product.
Now, we will put an API Key authentication plugin on top of the “emails” service. This will ensure that no bad actors try to get access to our APIs.
Rate-limit Plugins
We will also add a rate-limit plugin (to limit the number of API hits) on the different routes.
- Transactional (600 per minute) – Since this API is triggered by other flows, we need a high rate limit.
- Marketing (1 per minute) – Since this is manually triggered, we don’t need to go beyond 1 per minute
In order to further enhance our security, we will allow only certain IP addresses to be able to access our transactional email route as it will be triggered only by our internal systems, and we know the IP address range for our internal systems.
We will set it open to the world (Potentially insecure) for the marketing emails as the marketing peeps should be able to access it from any cafe that they wish to work out of.
Now we want only authorized consumers to access the APIs, so we will set up a consumer and add the API authentication credentials for them to use.
Now our email service is ready to serve consumers. We can integrate it into our code and give it to the marketing peeps for them to use it manually.
Wrapping Things Up
As you can see, using Kong as an API Gateway is simple and takes the hassle of managing APIs. Kong provides many other features like upstreams, certificate management, request and response transformation, serverless code execution, logging, and CORS, which are very helpful when you wish to develop APIs quickly.
I rest my case!
NGINX and other reverse proxy servers are simply blown out of the water by the ease of configurability and sheer dexterity that KONG provides out of the box.
If you have the same love as we do for Engineering, we encourage you to check out the careers page . Be a part of our passionate journey towards making stellar products!
Until we see you next time with another tech story!
Originally published at: https://decentro.tech/blog/why-we-moved-from-nginx-to-kong-api-gateway/
This content originally appeared on DEV Community and was authored by Decentro
Decentro | Sciencx (2021-12-08T07:29:35+00:00) We DON’T Need NGINX Anymore. Hello, KONG API Gateway!. Retrieved from https://www.scien.cx/2021/12/08/we-dont-need-nginx-anymore-hello-kong-api-gateway/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.