The next iteration of KrakenD is right around the corner and the Devops Faith team and the rest of the community we are working together to launch the
0.4 release before end of year. The jump from the
0.3.9 of the binary and the
0.3 of the framework to the
0.4 will bring a lot of interesting stuff but we also need to do a remarkable change in the code for a brighter future: kill external dependencies with fire.
Goals for version
These are the major goals we have set to release this version:
- Remove all the external dependencies from the framework
- Standardize the way of creating and adding plug-ins to the framework
- Open source the enterprise components
As a side effect to all this refactoring is that existing implementations will require updating the code to fix some
import statements. The release keeps all the declared interfaces and exposed structs and functions but the dependencies are now external.
External dependencies, go away!
Having external dependencies in the framework allowed us in the beginning to easily create and add adapters to KrakenD without any effort. We chose this path in the initial implementation of the project and we dragged it until now, and this is a common practice in thousands of projects.
The numbers might not seem scary to you, but the implementation of the last released version of the framework (
0.3) depends on 8 third party libs, hurting the project build times and its stability. We wanted to stop adding dependencies to the project and provide a way to have them outside.
The 0.4 version will depend only on the standard lib. All the adapters will be removed from the project and, in some cases (like the
config package), some basic alternative will be provided out-of-the-box. By doing this, the project gets closer to the
Of course this doesn’t mean that the features referenced by those adapters will be removed, they will be included in the final distributed binary and the code will be curated the same way we do with the framework.
So, where are these components now? All the components are listed in the krakend-contrib repository. Subscribe to it to follow the complete list of available components and middleware.
0.4 release extends the flexibility of the
0.3 version by adding the
encoding.Get functions to deal with injecting custom encoders, and by standarizing the use of the
config.ExtraConfig struct, so each component can define a custom namespace for the extra config it could require.
It’s in the roadmap to even create a customizable
proxy.Factory implementation using this feature, so more accurate management could be achieved without requiring a single extra code line.
Component changes in
As a continuation of what we explained in the previous post Why are we open sourcing our Enterprise version? the following new components are included in the 0.4 (The
X marks those already available at the time of writing)
[X] - ratelimit [X] - circuitbreaker [X] - oauth2-client [ ] - metrics proxy and router [ ] - security router [ ] - cmd package
New components added:
[X] - martian
And the list of the 8 components that we mentioned before that move to it’s dedicated repository:
[X] - config/viper [X] - encoding/xml [X] - encoding/rss [X] - logging/gologging [X] - sd/etcd [ ] - router/gin [ ] - router/negroni [ ] - router/gorilla
In order to provide an alternative to some basic and common features, these components were extended:
[X] - config [X] - encoding [X] - logging
Getting ready for the
Don’t panic! All the actual adapters will be moved but not removed.
In order to keep your code working, you just need to change the import section from
or run the upgrade script (that we will add to the project) in your repos.
To get the
xml and/or the
rss encodings, one more thing is required: registering it in your code
Checkout each package for more details about its configuration.
We will announce in Twitter and in this blog when the new version is released, follow us to stay up to date. Needless to say that we will be happy to review your contributions for the next release by sending your PRs to the