An introduction to KrakenD, the ultra-high performance API Gateway with middlewares. An opensource tool built using go that is currently serving traffic in major european sites.
7. Project overview
- Started Nov 2016
- Product built in Go language
- Concurrency
- High performance
- Coded after facing problems with unreliable APIs in production
- 3 core developers. More contributors are joining.
- 100% Open Source
11. Why KrakenD? There are many API GW solutions!
Yes, there are, but:
- Most of them cover features beyond an API Gateway
- Do not perform well or have poor performance
- Unfortunate architectures (e.g: share state between nodes)
- Single points of failure
- Paid, expensive and very limited. Monthly plans including X calls/month.
Convert that to reqs/sec!!
- Need complicated coding to make them work
- Not really extensible
12. The KrakenD
principles
- Reactive is key (even failing fast is
better than succeeding slow)
- The simpler, the better
- Everything is pluggable
- Each request must be processed in
its own request-scoped context
16. KrakenD features
● Aggregates information from many sources into single endpoints.
● Manipulates responses and allows you to group, wrap, rename...
● Filters and shrinks responses, hiding unwanted attributes or selecting them
● Throttles (rate limits) connections against KrakenD and against backends
● Protects your backends with circuit breakers and implements all kinds of
security measures.
● Discovers your service instances by integrating with your SD provider
● Extends your ecosystem as it supports a myriad of middlewares and plugins,
such as OAuth or security layers.
● Speaks different encoding formats and protocols.
● Fine control of manipulations, validations and filtering with DSL configurations
17. Security features
● User quota
● Support for SSL
● OAuth client credentials grant supported
● Restrict connections by host
● HTTP Strict Transport Security (HSTS)
● Clickjacking protection
● HTTP Public Key Pinning (HPKP)
● MIME-Sniffing prevention
● Cross-site scripting (XSS) protection
18. Use cases
● Increase user experience in apps. Less data consumption and faster responses
● Instant creation of a new REST API
● Add APIs in legacy systems
● Unify data coming from different sources and encodings
● Publish a fixed interface, let the backends evolve and change contracts.
● Quick Microservices adoption
● Create aggregated views from a lot of services
● Build MVPs using data from anywhere (bonus: backend for api2html)
● Smooth transition over different API version releases
25. KrakenD ecosystem
● KrakenD CE: KrakenD distribution ready to use.
● KrakenD framework: the core of the KrakenD is an open sourced library that
everyone can use, extend and modify. The project has several examples for
the integration with other third party libs (gorilla, negroni, gin, etc)
● KrakenD Contrib: A collection of components and middlewares to extend the
functionality
27. How KrakenD works?
KrakenD uses two different states: building and working.
Building: When the service is initially being prepared to serve the requests,
prepares all the middlewares and defines the pipes. Each pipe is binded to an
endpoint via their outer common interface, resulting in a HTTP handler function.
Only when the configuration is parsed and the service being prepared.
Working: The router maps every request to a HTTP handler function and triggers
the pipe execution. As HTTP handler functions are built in the previous step,
KrakenD doesn't penalize the performance depending on the number of endpoints
or the possible cardinality of the URI requested by the users.
29. Composed of a set of go packages designed as building
blocks to create pipes and processors between an exposed
endpoint and one or several backends resources
CONFIG ROUTER PROXY
31. The config package
The config package defines the entire service.
In the building stage, all the pipes are defined, with their tasks, helpers and
generators. Each pipe will be binded to an endpoint via their outer common
interface, resulting in a HTTP handler function.
32. The router package
The router layer is responsible for setting up the HTTP(S) services, binding the
endpoints defined by the config and transforming the HTTP request into proxy
requests before delegating the task to the inner layer (proxy).
When the internal proxy layer returns a response, the router layer converts it into a
proper HTTP response and sends it to the user.
This layer can be easily extended in order to use any HTTP router, framework or
middleware. Adding transport layer adapters for other protocols (Thrift, gRPC,
AMQP, NATS, etc) is in the roadmap.
33. The proxy package
Where most of the KrakenD components and features are placed. It defines two
important interfaces, designed to be stacked:
● Proxy is a function that converts a given context and request into a response.
● Middleware is a function that accepts one or more proxies and returns a single
proxy wrapping them.
This layer transforms the request received from the router into a single or several
requests to your backend services, processes the responses and returns a single
response.
34. Middlewares
Middlewares generate custom proxies that are chained depending on the workflow
defined in the configuration until each possible branch ends in a transport-related
proxy.
Each of these generated proxies is able to transform the input or even clone it
several times and pass it or them to the next element in the chain.
They can modify the received response or responses adding all kinds of features to
the generated pipe.
35. Middleware examples (open source)
● Balancing: uses some type of strategy for selecting a backend host to query.
● Concurrent: improves the QoS by sending several concurrent requests to the
next step of the chain and returning the first successful response using a
timeout for canceling the generated workload.
● Logging: logs the received request and response and also the duration of the
segment execution.
36. Middleware examples (open source)
● Merging: a fork-and-join middleware. Splits the process of the request into
several concurrent processes, each one against a different backend, and to
merge all the received responses from those created pipes into a single one. It
applies a timeout, as the concurrent one does.
● HTTP: completes the received proxy request by replacing the parameters
extracted from the user request in a defined URL Pattern.
● More middlewares and components:
https://github.com/devopsfaith/krakend-contrib
