5 ms·

The article touches on NGINX and Lua for API gateways, and that's an approach I like very much. The NGINX website has a bunch of well-written training posts abo

by jph 6y ago

The article touches on NGINX and Lua for API gateways, and that's an approach I like very much. The NGINX website has a bunch of well-written training posts about microservices and gateways. https://www.nginx.com/resources/library/designing-deploying-microservices/ https://www.nginx.com/resources/library/designing-deploying-...

sriku 6y ago
Kong is an API gateway that builds on top of nginx - https://konghq.com/kong/ https://konghq.com/kong/
- adolph 6y ago
  Kong is built on OpenResty which is NGINX with a Lua JIT. https://github.com/Kong/kong/issues/484 https://github.com/Kong/kong/issues/484 https://openresty.org/en/ https://openresty.org/en/
  - benatkin 6y ago
    KrakenD is an open source API gateway written in Go. I think they started off the same way I would, by extending nginx or a fork, or by using Go. I am not sure what I would choose. https://www.krakend.io/ https://www.krakend.io/
- jively 6y ago
  Going to jump on the shilling thread here and recommend Tyk. 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. https://tyk.io https://tyk.io /Shill
  - spacewander 6y ago
    > It also has the same performance curve as OpenResty these days Any data for this claim?
    - jively 6y ago
      From customers that have performance tested us against Kong and NGinX during competitive tender (where we also won the business). Unfortunately those aren't public. There's a decent blog post my head of research did a while ago: https://tyk.io/performance-tuning-your-tyk-api-gateway/ https://tyk.io/performance-tuning-your-tyk-api-gateway/
spacewander 6y ago
For API gateways, I recommend APISIX: https://github.com/apache/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-why-you-rarely-see-database-benchmarks https://www.brentozar.com/archive/2018/05/the-dewitt-clause-... [2]: https://konghq.com/evaluation-agreement/ https://konghq.com/evaluation-agreement/ Read the 1.5(e).
- jively 6y ago
  Go's GC is excellent btw, a massive benefit is also that you don't need the whole Java VM to run your app. 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.

by jph 6y ago

sriku 6y ago

Kong is an API gateway that builds on top of nginx - https://konghq.com/kong/ https://konghq.com/kong/

adolph 6y ago
Kong is built on OpenResty which is NGINX with a Lua JIT. https://github.com/Kong/kong/issues/484 https://github.com/Kong/kong/issues/484 https://openresty.org/en/ https://openresty.org/en/
- benatkin 6y ago
  KrakenD is an open source API gateway written in Go. I think they started off the same way I would, by extending nginx or a fork, or by using Go. I am not sure what I would choose. https://www.krakend.io/ https://www.krakend.io/
jively 6y ago
Going to jump on the shilling thread here and recommend Tyk. 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. https://tyk.io https://tyk.io /Shill
- spacewander 6y ago
  > It also has the same performance curve as OpenResty these days Any data for this claim?
  - jively 6y ago
    From customers that have performance tested us against Kong and NGinX during competitive tender (where we also won the business). Unfortunately those aren't public. There's a decent blog post my head of research did a while ago: https://tyk.io/performance-tuning-your-tyk-api-gateway/ https://tyk.io/performance-tuning-your-tyk-api-gateway/

spacewander 6y ago

For API gateways, I recommend APISIX: https://github.com/apache/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-why-you-rarely-see-database-benchmarks https://www.brentozar.com/archive/2018/05/the-dewitt-clause-... [2]: https://konghq.com/evaluation-agreement/ https://konghq.com/evaluation-agreement/ Read the 1.5(e).

jively 6y ago
Go's GC is excellent btw, a massive benefit is also that you don't need the whole Java VM to run your app. 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.