Handling Cross Cutting Concerns
Whenever we design and develop a large software application, we make use of a layered architecture. For instance, in a web application, it is quite common to see an architecture similar to the following:
Here, we see that the application is organized into a web layer, a business layer, and a data layer.
In a layered architecture, there are specific parts that are common to all these different layers. Such parts include:
All these features are applicable across layers, hence it makes sense to implement them in a common way.
Aspect Oriented programming is a well established way of handling these concerns. Use of constructs such as filters and interceptors is common while implementing them.
The Need for API Gateways
When we talk about a microservices architecture, we deal with multiple microservices talking to each other:
Where do you implement all the features that are common across microservices?
- Rate limiting
That’s where the API Gateway comes into the picture.
How Does an API Gateway Work?
In microservices, we route all requests — both internal and external — through API Gateways. We can implement all the common features like authentication, logging, auditing, and rate limiting in the API Gateway.
For example, you may not want Microservice3 to be called more than 10 times by a particular client. You could do that as part of rate limiting in the API gateway.
You can implement the common features across microservices in the API gateway. A popular API gateway implementation is the Zuul API gateway.
Just like AOP handles cross cutting concerns in standalone applications, API gateways manage common features for microservices in an enterprise.