4 ms·

Having an API gateway between the internet and your service(s) is a great idea and one I’ve implemented no less than 3 times. But you should really just roll yo

by vrosas 2y ago

Having an API gateway between the internet and your service(s) is a great idea and one I’ve implemented no less than 3 times. But you should really just roll your own. It’s a few dozen lines of code with go’s standard library reverse proxy and gives you way more flexibility than trying to yaml-configure someone else’s.

szarapka 2y ago
Unless you have a wild use-case that hasn't been tackled by what's out there, why on earth would rolling your own be a good idea? Building a proper, secure, and performant API gateway is NOT a few dozen lines of code. There are some super robust (and fast) Go API gateways that take care of all the things you didn't think about when trying to roll your own.
- vrosas 2y ago
  I can absolutely assure you that building a fast and secure gateway is not as hard as you seem to be implying. This is, again, based on my real world experience.
  - Aeolun 2y ago
    But maybe your experience just means you’ve never had the same problems as the authors of the libraries?
    - vrosas 2y ago
      That’s the point, I’m solving my problems not using the kitchen sink solution
lfmunoz4 2y ago
No idea why you would roll your own, easiest thing is run nginx in docker. No way writing your own is the first thing you should do.
- vrosas 2y ago
  Until you want your gateway to handle some complex auth or routing rules and don’t want to learn a whole new programming language to implement that.
  - dingnuts 2y ago
    this is such a wild take to me. why on earth are there complicated routing rules happening at the API gateway at all? In MY real world experience, the API gateway does some sort of very simple routing to various services and any complex auth or routing rules would be the service's responsibility. If the API gateway has your application logic in it it's not a separate component at all. How complex can you really get with HTTP requests anyway?
    - mozman 2y ago
      think about two product people with opposing goals. that’s how you get a mess. nothing technical
    - vrosas 2y ago
      Authn is gateway’s responsibility. Authz is subservice’s.
alphabettsy 2y ago
Completely disagree. Use something off the shelf that’s mature and tested until you encounter such complexity that it’s no longer feasible or practical.
- nilptr 2y ago
  Two sides of the same coin! Use something that solves 1000 use cases of which yours is one. Some would say that's simplicity while others would say that's complexity. When it breaks do you know why? Can you fix it properly or are just layering band-aid on a bigger problem inside the component. Or... build something that solves exactly your use-case but probably doesn't handle the other 1000 use-cases and needs to be put through trial-by-fire to fix all the little edge-cases you forgot about? Early in my career I opted for #1 but nowadays I generally reach for #2 and really try to nail the core problem I'm tackling and work around the gotchas I encounter.
denysvitali 2y ago
> But you should really just roll your own As someone who already did this (because no other solution with our needs was available), I strongly disagree. Most of the time, NGINX, Caddy, Traefik or APISIX are enough. The only time I felt the need to implement an API Gateway from scratch was to support a very specific use case with a specific set of constraints. No matter how robust the Go standard library is, implementing an API Gateway from scratch is rarely a good idea.
- vrosas 2y ago
  In my experience those specific sets of constraints come sooner or later. Someone is going to ask for some complex auth or routing rules and it’s easier to just write it in go than it is to learn a whole new DSL or lua to implement it.
  - denysvitali 2y ago
    Complex Auth: https://doc.traefik.io/traefik/middlewares/http/forwardauth/ https://doc.traefik.io/traefik/middlewares/http/forwardauth/ Complex routing rules: https://doc.traefik.io/traefik/routing/routers/ https://doc.traefik.io/traefik/routing/routers/ If you need something more than this, you're either in a very specific situation (where an API Gateway written from scratch might be a good idea) or that someone is doing something wrong
    - vrosas 2y ago
      Why would I want to write another service to handle auth? That’s somehow less complex than just writing it into my gateway?
  - Aeolun 2y ago
    I sort of agree with you, but only if you aren’t in a position to say ‘the software doesn’t support it’.
- tluyben2 2y ago
  We had a specific use case that was needed urgently which we couldn't get working with any of the standard systems, so we used Go. Works very well. It is sometimes simply a matter of time; we needed it before the morning (for a launch) and in discord/reddit people were providing solutions with haproxy, nginx, traefik etc that should work according to the docs but just didn't.

by vrosas 2y ago

szarapka 2y ago

Unless you have a wild use-case that hasn't been tackled by what's out there, why on earth would rolling your own be a good idea? Building a proper, secure, and performant API gateway is NOT a few dozen lines of code. There are some super robust (and fast) Go API gateways that take care of all the things you didn't think about when trying to roll your own.

vrosas 2y ago
I can absolutely assure you that building a fast and secure gateway is not as hard as you seem to be implying. This is, again, based on my real world experience.
- Aeolun 2y ago
  But maybe your experience just means you’ve never had the same problems as the authors of the libraries?
  - vrosas 2y ago
    That’s the point, I’m solving my problems not using the kitchen sink solution

lfmunoz4 2y ago

No idea why you would roll your own, easiest thing is run nginx in docker. No way writing your own is the first thing you should do.

vrosas 2y ago
Until you want your gateway to handle some complex auth or routing rules and don’t want to learn a whole new programming language to implement that.
- dingnuts 2y ago
  this is such a wild take to me. why on earth are there complicated routing rules happening at the API gateway at all? In MY real world experience, the API gateway does some sort of very simple routing to various services and any complex auth or routing rules would be the service's responsibility. If the API gateway has your application logic in it it's not a separate component at all. How complex can you really get with HTTP requests anyway?
  - mozman 2y ago
    think about two product people with opposing goals. that’s how you get a mess. nothing technical
  - vrosas 2y ago
    Authn is gateway’s responsibility. Authz is subservice’s.

alphabettsy 2y ago

Completely disagree. Use something off the shelf that’s mature and tested until you encounter such complexity that it’s no longer feasible or practical.

nilptr 2y ago
Two sides of the same coin! Use something that solves 1000 use cases of which yours is one. Some would say that's simplicity while others would say that's complexity. When it breaks do you know why? Can you fix it properly or are just layering band-aid on a bigger problem inside the component. Or... build something that solves exactly your use-case but probably doesn't handle the other 1000 use-cases and needs to be put through trial-by-fire to fix all the little edge-cases you forgot about? Early in my career I opted for #1 but nowadays I generally reach for #2 and really try to nail the core problem I'm tackling and work around the gotchas I encounter.

denysvitali 2y ago

> But you should really just roll your own As someone who already did this (because no other solution with our needs was available), I strongly disagree. Most of the time, NGINX, Caddy, Traefik or APISIX are enough. The only time I felt the need to implement an API Gateway from scratch was to support a very specific use case with a specific set of constraints. No matter how robust the Go standard library is, implementing an API Gateway from scratch is rarely a good idea.

vrosas 2y ago
In my experience those specific sets of constraints come sooner or later. Someone is going to ask for some complex auth or routing rules and it’s easier to just write it in go than it is to learn a whole new DSL or lua to implement it.
- denysvitali 2y ago
  Complex Auth: https://doc.traefik.io/traefik/middlewares/http/forwardauth/ https://doc.traefik.io/traefik/middlewares/http/forwardauth/ Complex routing rules: https://doc.traefik.io/traefik/routing/routers/ https://doc.traefik.io/traefik/routing/routers/ If you need something more than this, you're either in a very specific situation (where an API Gateway written from scratch might be a good idea) or that someone is doing something wrong
  - vrosas 2y ago
    Why would I want to write another service to handle auth? That’s somehow less complex than just writing it into my gateway?
- Aeolun 2y ago
  I sort of agree with you, but only if you aren’t in a position to say ‘the software doesn’t support it’.
tluyben2 2y ago
We had a specific use case that was needed urgently which we couldn't get working with any of the standard systems, so we used Go. Works very well. It is sometimes simply a matter of time; we needed it before the morning (for a launch) and in discord/reddit people were providing solutions with haproxy, nginx, traefik etc that should work according to the docs but just didn't.