Building DigitalOcean's API Gateway
mauricio.github.io
Building DigitalOcean's API Gateway
1–10 of 31 posts
Re: Building DigitalOcean's API Gateway
#2[deleted]
Re: Building DigitalOcean's API Gateway
#3The decision to roll their own in golang entirely and then reimplement rails auth in golang, vs reimplement auth in lua and lean on nginx for everything else could be examined more, feels a bit like they wanted to
do it in golang so nginx+lua was a non starter. Imagine how many crazy long tail problems nginx has already solved
There is always the benefit of building it up yourself and understanding it more deeply tho..
Re: Building DigitalOcean's API Gateway
#4The 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-...
Re: Building DigitalOcean's API Gateway
#5The decision to roll their own in golang entirely and then reimplement rails auth in golang, vs reimplement auth in lua and lean on nginx for everything else could be examined more, feels a bit like they wanted to do it in golang so nginx+lua was a non starter. Imagine how many crazy long tail problems nginx has already solved There is always the benefit of building it up yourself and understanding it more deeply tho…
> There is always the benefit of building it up yourself and understanding it more deeply tho..
That doesn't really fly though because unless you're the same coder on the same project forever, then eventually the team will have inherited someone elses code anyways. On average, might as well be OSS that's popular, well documented and has a community around it. Think about it, what would you rather inherit?
Of course, there are counter arguments. We want everything in golang because our Engineers know golang and most the CNCF toolset we use is in golang; Our usecase is simpler or specific and thus the general OSS solution would require to be tailored and that's more work than rolling our own; The OSS solution just isn't that good, and we think we can do better and have a competitive advantage by doing it internally; loads really.
Understanding it better though? On average seems like short term thinking.
Re: Building DigitalOcean's API Gateway
#6The decision to roll their own in golang entirely and then reimplement rails auth in golang, vs reimplement auth in lua and lean on nginx for everything else could be examined more, feels a bit like they wanted to do it in golang so nginx+lua was a non starter. Imagine how many crazy long tail problems nginx has already solved There is always the benefit of building it up yourself and understanding it more deeply tho…
We also recently started to roll our own API gateway in Java using Undertow.
Re: Building DigitalOcean's API Gateway
#7Not very knowledgable on the topic, but aren't API gateways like Amazon's and this one essentially vendor lock-in tools? Can you migrate your system across this type of gateways easily when you want to switch your vendor?
Re: Building DigitalOcean's API Gateway
#8The decision to roll their own in golang entirely and then reimplement rails auth in golang, vs reimplement auth in lua and lean on nginx for everything else could be examined more, feels a bit like they wanted to do it in golang so nginx+lua was a non starter. Imagine how many crazy long tail problems nginx has already solved There is always the benefit of building it up yourself and understanding it more deeply tho…
> There is always the benefit of building it up yourself and understanding it more deeply tho.. That doesn't really fly though because unless you're the same coder on the same project forever, then eventually the team will have inherited someone elses code anyways. On average, might as well be OSS that's popular, well documented and has a community around it. Think about it, what would you rather inherit? Of course,…
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 building it up from lower level is useful bc then I know how to form it into the thing that I need when all the new requirements come in, harder to do that with nginx.. but i might get hurt less along the way with nginx.
i guess the tl;dr is, mature eng org shouldn't have too many dark corners for mushrooms that are important to grow, and nginx+lua choice or straight golang choice should be made informed either way.. as always.. tradeoffs! =)
Re: Building DigitalOcean's API Gateway
#9The 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/
Re: Building DigitalOcean's API Gateway
#10Great! 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.