Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building DigitalOcean's API Gateway

mauricio.github.io

Post reply on HN
Print view View original

21–30 of 31 posts

Re: Building DigitalOcean's API Gateway

#21

Post by mchristen »

ownagefool wrote: post #19
nhoughto wrote: post #8

Earlier quoted context omitted.

yeah fly by night eng orgs sure, if you're DO your eng maturity (esp at this point) should be such that choices are being made knowingly, eyes open about future maintenance burden might be. If an api gateway is a foundational component at DO and having more control of it in golang is more important than getting long tail learnings for free building on top of nginx thats cool. If its a big important thing than buildin…

I'm not sure I'm confident that the popular (and being fair, strong) engineering orgs don't make the decision first and work backwards justifying it like most of us do. I have no specific exposure; but the rumour is with several big tech, it's write everything from scratch ( because we're special ), only reward impact ( rewriting from scratch ), and then shut it down because you can't maintain the thing ( too expensi…

It's not just big tech. I've seen multiple startups struggle and fail because ultimately they are building things to build things, not to solve the problem they set out to solve.

Re: Building DigitalOcean's API Gateway

#22

Post by xorcist »

sgt wrote: post #14
xorcist wrote: post #10

Great! You've made yourself a haproxy. The next step would be to make it dynamically configurable at runtime. Then there needs to be monitoring. And some tools for troubleshooting. There's something to be said for battle hardened tools.

How flexible is haproxy though? We recently started writing our own API gateway because we needed tight integration to existing services, even support some specific legacy authentication schemes.

Integrations are never maintenance free, however I found them much easier to write than to get a greenfield proxy up to snuff. It can call out to lua functions nowadays, but I haven't had to use that yet.

Re: Building DigitalOcean's API Gateway

#24

Post by adolph »

We even had to expose some of the Ruby code, mostly authorization policies, as a GRPC service so people wouldn’t have to rewrite all the policies they already had in place themselves.

This is an area of interest and learning for me. A pattern of use for gateways sometimes is to provide id/auth and access the backing services with a high priv service account. This can’t be 100% of the time because some applications perform their own authorization at the data level, as in User X can see data A but not B, or in service Q user type X can crud attributes a thru d but only user type Y can enter attribute e.

What other patterns do people see?

Re: Building DigitalOcean's API Gateway

#25

Post by jively »

sriku wrote: post #9
jph wrote: post #4

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-...

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

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

/Shill

Re: Building DigitalOcean's API Gateway

#26

Post by digianarchist »

xorcist wrote: post #10

Great! You've made yourself a haproxy. The next step would be to make it dynamically configurable at runtime. Then there needs to be monitoring. And some tools for troubleshooting. There's something to be said for battle hardened tools.

>The next step would be to make it dynamically configurable at runtime.

Like Caddy? https://caddyserver.com/

Re: Building DigitalOcean's API Gateway

#27

Post by mholt »

digianarchist wrote: post #26
xorcist wrote: post #10

Great! You've made yourself a haproxy. The next step would be to make it dynamically configurable at runtime. Then there needs to be monitoring. And some tools for troubleshooting. There's something to be said for battle hardened tools.

>The next step would be to make it dynamically configurable at runtime. Like Caddy? https://caddyserver.com/

Yeah, Dgraph is doing exactly this, building their own gateway as Caddy modules: https://twitter.com/caddyserver/status/1349434660107939841

> I'm impressed with how easy this was. I think I'm starting to understand why Caddy is not just a proxy, but a system for hosting apps.

Re: Building DigitalOcean's API Gateway

#28

Post by spacewander »

jively wrote: post #25
sriku wrote: post #9

Earlier quoted context omitted.

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

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…

> It also has the same performance curve as OpenResty these days

Any data for this claim?

Re: Building DigitalOcean's API Gateway

#29

Post by jively »

spacewander wrote: post #28
jively wrote: post #25

Earlier quoted context omitted.

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…

> It also has the same performance curve as OpenResty these days Any data for this claim?

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/

Re: Building DigitalOcean's API Gateway

#30

Post by spacewander »

jph wrote: post #4

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-...

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).

Post reply on HN