The best-documented API gateway among the competitors, with the most helpful people behind it.
What do you like best about the product?
- The documentation is great, compared to other competitors
- The focus on being a good API Gateway, no focus on side projects that lower the quality of the gateway
- The people behind it are very helpful - they really want to help and search for a solution
- The flexible configuration feature
- It was easy to deploy in our Kubernetes cluster
- Go plugin support, with a handy builder image supplied
- Uses security-first principles like zero-trust security policy
- The focus on being a good API Gateway, no focus on side projects that lower the quality of the gateway
- The people behind it are very helpful - they really want to help and search for a solution
- The flexible configuration feature
- It was easy to deploy in our Kubernetes cluster
- Go plugin support, with a handy builder image supplied
- Uses security-first principles like zero-trust security policy
What do you dislike about the product?
- Because of the stateless nature of everything, some business requirements are challenging to implement. But I can see the reasoning - speed matters.
- We were advertised the upcoming proxy plugins feature, but when it was dropped, we did not receive a formal update. It would be nice to keep track of which customers are interested in which features.
- Lack of an authentication system on a global level, but only endpoint level. Unmapped endpoints are thus not authenticated and we needed to rethink our plugins for things to work as they used to.
- Low customization options for authentication responses (returning different reasons in case of missing token, expired token, incorrect signature, ...).
- Not easy to do a transparent migration from another gateway system, but this will most likely be the case for every other gateway on the market. We need to integrate KrakenD to work exactly as our old gateway did.
- Its native plugin system is using Go, which I dislike. We cannot bump dependency versions when KrakenD's binary is using them already. This slows down patches and forces us to group them together and update them when KrakenD does. It feels archaic to have to deal with this in a modern programming language.
- We were advertised the upcoming proxy plugins feature, but when it was dropped, we did not receive a formal update. It would be nice to keep track of which customers are interested in which features.
- Lack of an authentication system on a global level, but only endpoint level. Unmapped endpoints are thus not authenticated and we needed to rethink our plugins for things to work as they used to.
- Low customization options for authentication responses (returning different reasons in case of missing token, expired token, incorrect signature, ...).
- Not easy to do a transparent migration from another gateway system, but this will most likely be the case for every other gateway on the market. We need to integrate KrakenD to work exactly as our old gateway did.
- Its native plugin system is using Go, which I dislike. We cannot bump dependency versions when KrakenD's binary is using them already. This slows down patches and forces us to group them together and update them when KrakenD does. It feels archaic to have to deal with this in a modern programming language.
What problems is the product solving and how is that benefiting you?
Replacing our current API Gateway, ultimately lowering maintenance.
Supporting future API Monetization & usage logging
Supporting future API Monetization & usage logging
There are no comments to display