How good is Krakend compared to Kong?

Question

I am stuck in choosing One API gateway from the three API gateways mentioned below:

1. KrakenD (https://www.krakend.io/)
2. Kong (https://konghq.com/kong/)
3. Spring Cloud Gateway (https://cloud.spring.io/spring-cloud-gateway/reference/html/)

My requirements are:

1. Good performance and must have majority of the API gateway features.
2. Supports aggregating data from two Different Micro-services API's.

All the three of them, looks good from the feature list and the performance wise. I am thinking of relaxing the second requirement, as I am not sure, whether that is a good practice or not.

Answer 1

API Gateway is a concept that is used in all kind of products, I really think the industry should start sub-categorizing these products as most of them are completely different from each other.

I'll try to summarize here the main highlights according to your requirements.

Both Kong and KrakenD offer the "majority" of API gateway functionalities. Although the word is fuzzy, at least all of them cover stuff like routing, rate limiting, authorization, and such.

Kong

Kong is basically an Nginx proxy that adds a lot of functionality on top of it using Lua.

When using Kong your endpoints have a 1:1 relationship with your backends. Meaning that you declare an endpoint in Kong that exposes data from one backend, and does the magic in the middle (authorization, limiting, etc). This magic is the essence of Kong and is based on Lua plugins (unfortunately, these are not written in C as Nginx is).

If you want to aggregate data from several backends into one single endpoint, Kong does not fit in your scenario.

Finally, Kong is stateful (it's impressive how they try to sell it the other way around, but this is out of the scope of this question). The configuration lives inside a database, and changes to the configuration are through an API that ends up modifying its internal Postgres or equivalent.

Performance is also inevitably linked to the existence of this database (and Lua), and going multi-region can be a real pain.

Kong functionality can be extended with Lua code.

In summary:

• Proxy with cross cutting concerns
• Nodes require coordination and synchronization
• Mutable configuration
• The database is the source of truth
• More pieces, more complexity
• Multi-region lag
• Requires powerful hardware to run
• Customizations in Lua

KrakenD

KrakenD is a service written from the ground up using Go, taking advantage of the language features for concurrency, speed, and small footprint. In terms of performance, this is the winning racehorse.

KrakenD's natural positioning is as a Gateway with aggregation. It's meant to connect lots of backend services to a single endpoint. It's mostly adopted by companies for feeding Mobile applications, Webapps and other clients. It implements the pattern Backend for Frontend, allowing you to define exactly and with a declarative configuration how is the API that you want to expose to the clients. You can choose which fields are taken from responses, aggregate them, validate them, transform them, etc.

KrakenD is stateless, you version your API the same way you do with the rest of the code, using git. And you deploy it in the same way you do with your application (e.g: a CI/CD pipeline that pushes a new container with the new configuration and is rolled out). As everything is on the config, there is no need to have a central database, neither nodes need communication with each other.

As per the customizations, with KrakenD you can create middlewares, plugins or just scripting in several languages: Go, Lua, Common Expression Language (CEL) -sort of JS- and Martian DSL.

In summary:

• On the-fly API creation using upstream services, with cross-cutting concerns (api gateway).
• Not a proxy, although it can be used as one.
• No node coordination
• No synchronization needed
• Zero complexity (docker container with a configuration file)
• No challenges for Multi-region
• Declarative configuration
• Immutable infrastructure
• Runs on micro and small machines in production without issues.
• Customizations in Go, Lua, CEL, and Martian DSL

Spring Cloud Gateway

(As well as Zuul) is used mostly by Java developers that want to stick in the JVM space. I am less familiar with this one, but it's design is also for proxying to existing services, adds also the cross-concerns of the API gateway.

I see it more as a framework that you use to deliver your API. With this product you need to code the transformations yourself in Java. The included gateway functionalitites are declarative as well.

--

I am hoping this sheds some light

Answer 2

My only and major blocker from using Kong for me is you can only extend Kong with LUA. Only small percentages of developers in the world familiar with LUA. That's why I choose KrakenD.