would be nice to see side by side comparison of tyk & kong features about lura

[alombarte]

@hbakhtiyor You are probably right. KrakenD might offer less features.

But have in mind that KrakenD does not intend in any way to support features that are not responsibility of an API Gateway. We don't think we should add anything to the project that is not strictly an API Gateway, such as authentication (instead of delegating it), response caching and alike... If people goes to microservices and are pro separation of concerns I believe the same should go for the products they use.

KrakenD won't be a one size fits all solution.

Also, this repository is a library/framework highly customizable and extendable and not a end-user product (although you can reach that point by compiling any of the examples). It's hard to see for me how to do this comparison correctly beyond showing the benchmarks for the api gateway functionality. Is there any functionality related to API-gateway that you have find in these two or other products that we are missing?

Thank you for your contribution!

[hbakhtiyor]

would like to see,

• rate limiting
• auth
• cache
• dev api portal scaffolding
• UI admin

[kpacha]

Thanks for the suggestions! We're working on the way the website walks the visitors through the feature list.

@hbakhtiyor :

1. rate limiting: https://github.com/devopsfaith/krakend-ratelimit (distributed)
2. auth: https://github.com/devopsfaith/krakend-contrib#security and some JOSE features in the roadmap. I think supporting more than just key/signature validations and other server-side checks it's out of the scope because it requires coordination and introduces lots of undesired problems
3. cache: again, I think it's out of the scope of the project. You can always place a cache layer (Varnish, CloudFront, etc) in front of KrakenD and the latter will inform the former using the http cache header.
4. dev api portal scaffolding: that's interesting... and in the roadmap. We are trying to figure out the proper way to implement it without adding too much effort to the user.
5. UI admin: http://www.krakend.io/designer

@grahamar :

what is a 'dynamic endpoint' for you?

If you're talking about parametrized urls, yes it's supported out-of-the-box.

If you're talking about routing using other params other than the URL, it is possible but less efficient and less standard. We'll add some examples for this use case.

If you're talking about managing the service configuration and hot-swapping it, no it's not. But there are some reasons for that:

1. performance: the KrakenD gateway builds the pipes at starting time
2. consistency: the api contract should be versioned
3. simplicity: developing consistency strategies for distributing configuration updates in an ecosystem of independent, non-coordinated and state-less services like KrakenD is completely out of the scope of the project (without adding some restrictions that will make the feature less attractive and the system, very error-prune)

I think building a custom docker container with your own configuration and using the resultant image as the artifact to deploy is the proper and easier way to proceed.

On the other hand, the small size of the docker images and the footprint of the solution makes it easier to manage the running instancies by the config version they are using and just use a blue-green deploy strategy to release your changes.

Finally, I think what separates an API gateway from an L7 router is what it does with the request and how it builds the proper response. I would say the former is a proxy/relay (and possibly some manipulators) and the latter, a service composing proxies/relays and manipulators for a specific set of client's use cases

[dirham]

Yeh but other api getaway not have this feature which is great
http://www.krakend.io/docs/features/response-manipulation/

[grahamar]

I could have missed it but, dynamic endpoints is a key feature of api gateways, which Tyk & Kong provide... It's pretty much what separates an API gateway from an L7 router.

[alombarte]

Closing as the comparison is not related to this repository (framework code). We take the suggestion for maybe a blog post or similar.

Thanks

[github-actions]

This issue was marked as resolved a long time ago and now has been automatically locked as there has not been any recent activity after it. You can still open a new issue and reference this link.