11–20 of 31 posts
Not 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?
The 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…
It was kinda "here's a script, load it on nginx and hope it works" so it required a considerable amount of work to make it reliable and testable. Golang actually has a lot of stuff already done for you in terms of proxying so that part of the gateway isn't really that large.
There was no simple way to reload configs on the fly (other than updating the file locally with something like chef or ansible and reloading nginx on all machines) and that made it harder to provide self service routes from the get go (it's much easier nowadays with Nginx Service Mesh).
Nowadays with the options available I don't think we'd build it from scratch anymore (we could even use Zuul 2 I think). I'd say our mistake was that we didn't open source it in the beginning to benefit from more external usage and contributions, the way it is tied to internal services nowadays makes this hard to pull off right now.
I am currently creating a cloud based API gateway for primary SMBs. The current gateways are quite complex to implement, and for the simpler use cases I believe it can be done better.
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 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…
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.
I think it's pretty good people are building these proxies as it's forcing the entrenched vendors to move.
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/
Earlier quoted context omitted.
Kong is an API gateway that builds on top of nginx - https://konghq.com/kong/
Kong is built on OpenResty which is NGINX with a Lua JIT. https://github.com/Kong/kong/issues/484 https://openresty.org/en/
Earlier quoted context omitted.
> 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 buildin…
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 expensive because we keep rewriting it from scratch ).
Is it like that in reality? I dunno, but we all have our problems.
Not 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?