Do I really need web-server alongwith API - gateway in microservice architecture

Question

In the current python application I'd like to redesign, I am using gunicorn along-with nginx. Now as we are moving to the cloud, it makes me think: do I really need nginx or rather any other web-server?

In our cloud architecture we would be using an API gateway via which we are planning to:

1. Expose API's over internet:
2. Do load balancing:
3. Enforce authentication and authorization.

Is there any other purpose of web-server which can't be accomplished with api-gateway?
Also is api-gateway just another fancy name for web-server?

Answer 1

I will answer by addressing what is meant by the term API gateway. An API gateway is an implementation of the facade design pattern. This pattern, as the name implies, simply means putting some component in front of some other components. In the context of a web application, a gateway API is a module which sits in front of your web services/endpoints. However, contrary to what you described, authentication and authorization are typically best suited to be separate modules/microservices within your architecture. Here is one way of setting up a gateway API service:

┌──────────────┐         (1)          ┌────────────────┐
│              ├─── authenthicate ──> │                │
│  gateway API │                      │ authentication │
│              │ <──── yes/no ────────┤                │
└───────┬───┬──┘                      └────────────────┘
        │   │         (2)
        │   └─────────────────────┐
    (3) │                         │
        │                         │
┌───────┴──────┐          ┌───────┴───────┐
│              │          │               │
│ web services │          │ authorization │
│              │          │               │
└──────────────┘          └───────────────┘

Under this design, all your components now have a single point for login/authentication. The authentication module just basically says yes or no, and this also means that you only need to maintain a single set of logic or code to handle all your authentication. This may seem trivial, but imagine how much work this would save a company like Google or Microsoft, which has dozens of publicly available products and services. Note that in practice your authentication might be tiered or layered. For example, you might have 1FA and 2FA levels of authentication, or something else.

The next step which happens is that the gateway API will hit the authorization module, to find out if the incoming request has sufficient rights to access the endpoint/service being requested. If it does not, then the gateway will reject the request. If it does, then it will allow the request to hit the appropriate webservice.

Appreciate that once authentication and authorization are out of the way, the gateway API is basically just a big router, which maps incoming requests to some particular endpoint in one or more of your applications. One other benefit of this microservice design worth mentioning is that if you ever had to change your authentication provider, or authorization logic, you would only need to change that module. Assuming you wisely code to an interface, the change needed in your applications should be minimal.

Here is a link to the documentation for Spring's Cloud Gateway framework. In this case, a Spring Boot application is being used as an implementation of the gateway API.