, take a back seat, there's a new player in town! NGINX For many developers out there, NGINX would be the primary choice for reverse proxy. However at , our API platform for banking integrations, we moved on to something more exciting! 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 is 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. We have a microservice that takes care of sending emails.  We'll declare a Service with the name “emails” (Pretty innovative.. yep!). 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. 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. We rest our case, thus!

Why We Switched from NGINX Is to KONG API Gateway

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

8 Important Learnings from 9 Months of Product Development

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

10 Threats to an Open API Ecosystem

10 Indications That You Should Invest in Automation Via APIs

10 Best Practices for Securing Your API

8 Important Learnings from 9 Months of Product Development

100 Days of AI Day 1: From Newsletter to Podcast, Leveraging AI for Audio Transformation

10 Threats to an Open API Ecosystem

10 Indications That You Should Invest in Automation Via APIs

10 Best Practices for Securing Your API

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps