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..
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.
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.
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.
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.
Maybe if you're running one instance of your API server.
But if you're not then API Gateways end up being significantly simpler.
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.