Document updated on Nov 26, 2018
KrakenD Community Edition Documentation
KrakenD is an extensible, declarative, high-performance open-source API Gateway.
Its core functionality is to create an API that acts as an aggregator of many microservices into single endpoints, doing the heavy-lifting automatically for you: aggregate, transform, filter, decode, throttle, auth, and more.
KrakenD needs no programming as it offers a declarative way to create the endpoints. It is well structured and layered, and open to extending its functionality using plug-and-play middleware developed by the community or in-house.
KrakenD focuses on being a pure Layer 7 API gateway, not coupled to the HTTP transport layer, and it has been in production in large Internet businesses since early 2017. See who is using KrakenD and use cases
KrakenD is written in Go. Our engine joined The Linux Foundation on 2021 codenamed as the Lura Project and was previously known as the Krakend Framework.
Why an API Gateway?
When consumers of API content (especially in microservices) query backend services, the implementations suffer a lot of complexity and burden with the sizes of their microservices responses.
KrakenD is an API Gateway that sits between the client and all the source servers, adding a new layer that removes all the complexity to the clients, providing them only the information that the UI needs.
KrakenD goes beyond other tools that are mere reverse proxies, and acts as an aggregator of many sources, allowing you to consume in a single call many endpoints. It allows you to group, validate, wrap, transform and shrink requests and responses. Additionally, it supports a myriad of middleware and plugins that allow you to extend the functionality, such as adding OAuth2 authorization, security layers, circuit breaking, rate-limiting, connectivity, logging, metrics, traces, and much more.
A practical example
A mobile or javascript developer needs to construct a single front page that requires data from several calls to their backend services, e.g.:
api.store.server/products
api.store.server/marketing-promos
api.users.server/users/{id_user}
api.users.server/shopping-cart/{id_user}
The mobile application needs to retrieve data from these four different sources, authorize each of the services, wait for each round trip, and pick only a few fields from the responses (doesn’t need the full response). What if, instead of doing these calls, the mobile client could call a single endpoint to KrakenD to get exactly what it needs?:
api.krakend.server/frontpage/{id_user}
This is what KrakenD can do:
With this approach, the mobile client isolated itself from the backend implementation. As a result, the backends do not need to address several shared concerns (authentication, rate-limiting, filtering malicious requests, etc.). Furthermore, whenever the backends change their contract, the API contract for the mobile client remains the same, and you can update the gateway via a simple change of configuration.
The client becomes faster, as it needs to handle a single HTTP connection for this use case, and there is a difference in size between the amount of data generated by the backends and what is finally traveling to the client.
As KrakenD is declarative and GitOps oriented, the mobile developers can update the configuration. There is no need to wait for the backend/infra team to make the changes.