| For API gateways, I recommend APISIX: https://github.com/apache/apisix/ Claim: I am the core developer of APISIX, and I am also the core developer of OpenResty (known as Nginx + Lua). I have written Go for several years and I have contributed to github.com/golang/go. We have done some benchmarks around APISIX, Kong, Tyk. APISIX is the fastest (APISIX > Kong > Tyk).
All of them have rich features and fantasy GUI. If people really care about the performance, it would be good to consider APISIX. Remember to benchmark every candidates in your own environment, even if you do not benchmark them correctly (every vendor complains others can't do benchmark correctly, some even don't allow others to do benchmark[1][2]), it is the way you use them in the production. Advertisement time is over. Let's talk something irrelevant to my employer. If you care about performance, forget about writing a plugin with a guest language. A guest language is a language doesn't supported by the gateway natively, like Go in Kong and Lua in Tyk. The performance waste in ctx serialization and IPC are huge. I have seen these complains for more than one. > Imagine how many crazy long tail problems nginx has already solved There is a problem I believe that API Gateways based on Go can't solve it unless Go have made its GC as good as Java's. Some people have consulted with me about replacing their Go implementation to a Nginx or Envoy one because this problem. [1]: https://www.brentozar.com/archive/2018/05/the-dewitt-clause-... [2]: https://konghq.com/evaluation-agreement/ Read the 1.5(e). |
For pure performance, go write something in C or Rust. In fact for folks that are obsessed with performance rolling your own is the only option. Which is probably why the DO team went down this path.
For most use cases the benefit of working in your dev teams context / language of choice outweighs performance considerations.
And at Tyk the go plugins are native, you can slow down the GC activity to really boost performance if you have RAM to spare. Speed isn't an issue.
Ultimately it comes down to what you are trying to accomplish. What's best for your dev team? How can you innovate faster? How can you get this done cost effectively.
Performance comparisons are a dick measuring contest that are rarely relevant to the problem you are trying to solve.