5 ms·

What is the main benefit to running a gateway? Auth should already be handled by the api and adding things like rate limiting, ip address filtering ,caching and

by matt-p 4y ago

What is the main benefit to running a gateway? Auth should already be handled by the api and adding things like rate limiting, ip address filtering ,caching and so on are ridiculously trivial..

zedpm 4y ago
While you _can_ tack all of those things on to your API, many people (myself included) prefer to separate those concerns. A dedicated API Gateway can prevent a lot of additional load from hitting the backend services. A gateway can also be a nice abstraction of the public interface from the underlying service(s).
VWWHFSfQ 4y ago
Most of the time an "API Gateway" provides nothing. Usually this kind of service is just looking at the request path and maybe the Authorization header. In general it's just a useless hop in the TCP connection chain from the client to the server.
- salmo 4y ago
  I feel “useless hop in TCP connection chain” is treated as a virtue in “modern architecture.” Somehow micro services and cloud native turned into that. So yeah, slow response times, wasted infrastructure and most work put into I/O and serialization/deserialization. I think we forgot what actual monoliths look like and just kept decomposing… I guess that is an appropriate term.
  - userbinator 4y ago
    Cloud providers love it: More pieces to charge you for.
- arinlen 4y ago
  > Most of the time an "API Gateway" provides nothing. This personal assertion only holds if you somehow chose to adopt a component that you need, or blindly adopt components even though you have no idea what you're doing. Discussing these scenarios is pointless and a waste of time though. Meanwhile, reverse proxies and ingress controllers are fundamental components in any service that outgrows a box under the desk, and a API Gateway is nothing more than a specialized reverse proxy whigh offers some high level features as part of it's happy path.
cheriot 4y ago
It's been useful when domains are routed to a bunch of microservices internally. It keeps the gateway functionality centralized. For people using kubernetes, the new k8s Gateway API will obviate a bunch of the gateway tools out there.
threeseed 4y ago
> rate limiting, ip address filtering ,caching and so on are ridiculously trivial Maybe if you're running one instance of your API server. But if you're not then API Gateways end up being significantly simpler.
- matt-p 4y ago
  It's really interesting. I just sync state and store short term cache in redis, it's what I do when building any internal API anyway, so why any different with an external API. API servers sit behind a load balancer.
- CoolCold 4y ago
  > Maybe if you're running one instance of your API server. I'm not sure how it differs, can you explain more? From my perspective each API instance is just one more `server x.x.x.x:port` in my `upstream someapi { ... }` section in Nginx config. Be it 1 or 20. No difference from regular Loadbalancing as I see it. For multiple APIs (api1, api2...) you end up with different `location {}` and using specific `upstream {..}` blocks upon request from deb/backend team.
arinlen 4y ago
> What is the main benefit to running a gateway? An API gateway is an adapter. You can build a web API out of multiple independent web services, like microservices or simply versioned APIs. On top of that you can do anything a proxy does, like load balancing, TLS termination, rate limiting, monitoring, etc. Basically a API gateway is a higher-level abstraction over a proxy which saves some time and effort implementing some basic features. > Auth should already be handled by the api (...) That won't make a dent if you are running a single instance of a single service. Once you start to run multiple instances of multiple services then things start to break down.
sytringy05 4y ago
the same benefit you get from most reverse proxies. If you dont need it, then nothing. If you do need it, it's critical. If you: - have more than 1 upstream service to hide behind your api.bigcorp.com name? - want to enforce standard authn/authz patterns across lots of teams/backend services? - want a standard approach to all the Quality of Service management? - want to have a well defined lifecycle for your APIs? - want to have a portal that describes the APIs, how they work and facilitate users getting access to them? API Gateways are a thing because web servers that started out being used as reverse proxies were not that easy to configure and just did way too much web server stuff. API gateways made this easier, and added a host of security measures to make it somewhat safer when presenting APIs to the internet. Then API management came along as a first class concern for orgs who want others to use their APIs. It's good to see some FOSS innovation in this domain, most of the real open source API gateways are a huge mess. Kong is great, but the really useful stuff is part of the paid enterprise platform.
- jjzhiyuan 4y ago
  Hi, could you please share more about “the really useful stuff” part?
  - beoberha 4y ago
    I’m assuming he means things like third party auth connectors
    - sytringy05 4y ago
      the main ones are OIDC plugin, the serverless plugin, advanced req and resp transformer plugins. auth connectors are useful, but most orgs I work with are using OIDC or SAML

by matt-p 4y ago

What is the main benefit to running a gateway? Auth should already be handled by the api and adding things like rate limiting, ip address filtering ,caching and so on are ridiculously trivial..

zedpm 4y ago

While you _can_ tack all of those things on to your API, many people (myself included) prefer to separate those concerns. A dedicated API Gateway can prevent a lot of additional load from hitting the backend services. A gateway can also be a nice abstraction of the public interface from the underlying service(s).

VWWHFSfQ 4y ago

Most of the time an "API Gateway" provides nothing. Usually this kind of service is just looking at the request path and maybe the Authorization header. In general it's just a useless hop in the TCP connection chain from the client to the server.

salmo 4y ago
I feel “useless hop in TCP connection chain” is treated as a virtue in “modern architecture.” Somehow micro services and cloud native turned into that. So yeah, slow response times, wasted infrastructure and most work put into I/O and serialization/deserialization. I think we forgot what actual monoliths look like and just kept decomposing… I guess that is an appropriate term.
- userbinator 4y ago
  Cloud providers love it: More pieces to charge you for.
arinlen 4y ago
> Most of the time an "API Gateway" provides nothing. This personal assertion only holds if you somehow chose to adopt a component that you need, or blindly adopt components even though you have no idea what you're doing. Discussing these scenarios is pointless and a waste of time though. Meanwhile, reverse proxies and ingress controllers are fundamental components in any service that outgrows a box under the desk, and a API Gateway is nothing more than a specialized reverse proxy whigh offers some high level features as part of it's happy path.

cheriot 4y ago

It's been useful when domains are routed to a bunch of microservices internally. It keeps the gateway functionality centralized. For people using kubernetes, the new k8s Gateway API will obviate a bunch of the gateway tools out there.

threeseed 4y ago

> rate limiting, ip address filtering ,caching and so on are ridiculously trivial Maybe if you're running one instance of your API server. But if you're not then API Gateways end up being significantly simpler.

matt-p 4y ago
It's really interesting. I just sync state and store short term cache in redis, it's what I do when building any internal API anyway, so why any different with an external API. API servers sit behind a load balancer.
CoolCold 4y ago
> Maybe if you're running one instance of your API server. I'm not sure how it differs, can you explain more? From my perspective each API instance is just one more `server x.x.x.x:port` in my `upstream someapi { ... }` section in Nginx config. Be it 1 or 20. No difference from regular Loadbalancing as I see it. For multiple APIs (api1, api2...) you end up with different `location {}` and using specific `upstream {..}` blocks upon request from deb/backend team.

arinlen 4y ago

> What is the main benefit to running a gateway? An API gateway is an adapter. You can build a web API out of multiple independent web services, like microservices or simply versioned APIs. On top of that you can do anything a proxy does, like load balancing, TLS termination, rate limiting, monitoring, etc. Basically a API gateway is a higher-level abstraction over a proxy which saves some time and effort implementing some basic features. > Auth should already be handled by the api (...) That won't make a dent if you are running a single instance of a single service. Once you start to run multiple instances of multiple services then things start to break down.

sytringy05 4y ago

the same benefit you get from most reverse proxies. If you dont need it, then nothing. If you do need it, it's critical. If you: - have more than 1 upstream service to hide behind your api.bigcorp.com name? - want to enforce standard authn/authz patterns across lots of teams/backend services? - want a standard approach to all the Quality of Service management? - want to have a well defined lifecycle for your APIs? - want to have a portal that describes the APIs, how they work and facilitate users getting access to them? API Gateways are a thing because web servers that started out being used as reverse proxies were not that easy to configure and just did way too much web server stuff. API gateways made this easier, and added a host of security measures to make it somewhat safer when presenting APIs to the internet. Then API management came along as a first class concern for orgs who want others to use their APIs. It's good to see some FOSS innovation in this domain, most of the real open source API gateways are a huge mess. Kong is great, but the really useful stuff is part of the paid enterprise platform.

jjzhiyuan 4y ago
Hi, could you please share more about “the really useful stuff” part?
- beoberha 4y ago
  I’m assuming he means things like third party auth connectors
  - sytringy05 4y ago
    the main ones are OIDC plugin, the serverless plugin, advanced req and resp transformer plugins. auth connectors are useful, but most orgs I work with are using OIDC or SAML