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:
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?
An API is also an abstraction of the web server. The application (such as a website or a mobile app) will make an API call for a set of data to display for the end user to consume. The request is made via the API that accesses the web server to retrieve the requested data, which is populated in the user interface.
The API Gateway. An API Gateway is the element that coordinates and orchestrates how all the requests are processed in a Microservices architecture, and this also includes to the Serverless model. An API Gateway includes an HTTP server where routes are associated with a Microservice or with a FaaS function.
If you don't have API Gateways, the client apps must send requests directly to the microservices and that raises problems, such as the following issues: Coupling: Without the API Gateway pattern, the client apps are coupled to the internal microservices.
Support for Mixing Communication Protocols Internal microservices benefit from using different communication protocols by using API gateway. An API gateway can provide a unified REST-based API for various protocols to choose the best internal architecture for the applications.
Recently, Google announced its own api-gateway. The time is ripe to take a look at why microservice architecture needs them and how they currently look without the api gateway in place. Let's look at a microservice architecture without an api gateway. Each microservice apart from its core functionality, traditionally have been doing these as well,
An API gateway separates external public APIs From internal microservice APIs, allowing for microservices to be added and boundaries changed. The result is the ability to refactor and right-size microservices over time, without negatively impacting externally-bound clients.
Using a single API Gateway in the architecture across multiple web portal applications and microservices is an important consideration towards the goal of reusability of components and cost optimization. Amazon API Gateway provides a highly scalable solution to create and publish RESTful and WebSocket APIs.
These can be decoupled from the application itself. API Gateway doesn't need any introduction now. An API gateway can be considered as yet another microservice in your architecture that does all the aforementioned functionalities.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With