3 ms·

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 co

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

ownagefool 6y ago
> 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.
- nhoughto 6y ago
  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! =)
  - ownagefool 6y ago
    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 expensive because we keep rewriting it from scratch ). Is it like that in reality? I dunno, but we all have our problems.
    - mchristen 6y ago
      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.
sgt 6y ago
We also recently started to roll our own API gateway in Java using Undertow.
mlinhares 6y ago
If Nginx+Lua had better development and testing support (back in 2016, I haven't really looked at it in a while) we might have gone that way. 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.
spyspy 6y ago
I’ve built an api gateway in go at my last company and my current one, so I’m actually a fan of the pattern. Usually the decision revolves around complex auth and permissioning rules that already exist in go, and would be a pain to rewrite. It also allows for custom multiplexing of requests to hit multiple downstream APIs. It also makes monitoring simpler, since you can have a view of your entire platform by just monitoring a single service. A reverse proxy in go is dead simple to write and maintain, especially if it matches the rest of your stack.

ownagefool 6y ago

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

nhoughto 6y ago
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! =)
- ownagefool 6y ago
  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 expensive because we keep rewriting it from scratch ). Is it like that in reality? I dunno, but we all have our problems.
  - mchristen 6y ago
    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.

sgt 6y ago

We also recently started to roll our own API gateway in Java using Undertow.

mlinhares 6y ago

If Nginx+Lua had better development and testing support (back in 2016, I haven't really looked at it in a while) we might have gone that way. 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.

spyspy 6y ago

I’ve built an api gateway in go at my last company and my current one, so I’m actually a fan of the pattern. Usually the decision revolves around complex auth and permissioning rules that already exist in go, and would be a pain to rewrite. It also allows for custom multiplexing of requests to hit multiple downstream APIs. It also makes monitoring simpler, since you can have a view of your entire platform by just monitoring a single service. A reverse proxy in go is dead simple to write and maintain, especially if it matches the rest of your stack.