https://www.nginx.com/resources/library/designing-deploying-...
Tyk is an open source API Gateway written in Go, it's also the most extensible OSS API gateway as it doesn't force you to learn Lua (Go, Python and Lua plugins are supported in-process) to extend it. In fact DO could have written their auth logic in rails with Tyk's gRPC plugin support.
It also has the same performance curve as OpenResty these days as it's been around for over 5 years and used in critical high-performance infrastructure projects.
/Shill
Any data for this claim?
There's a decent blog post my head of research did a while ago:
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.