This story is the written form of the series of videos I made on the same topic. If you would like to watch more concepts about microservices, watch them here is this playlist
Lets learn why do we need API gateway and there advantages and disadvantages.
If you see the below product page, its fetching data from many microservices
- Number of items in the shopping cart
- Order history
- Customer reviews
- Low inventory warning
- Shipping options
- Various recommendations, including other products this product is frequently bought with, other products bought by customers who bought this product, and other products viewed by customers who bought this product
- Alternative purchasing options
When using a monolithic application architecture, client retrieves these data by making a single one or two calls to the application
GET http://myecommerce.com/productdetails/productId
In contrast, when using the microservices architecture, the data displayed on the product details page is owned by multiple microservices.
There are three patterns to access data from Microservices
1. Direct requests:
Client makes direct API calls to all of the microservices and gets the information needed to render the page
Problem 1 : Too many request , Complex JS/Android code to handle
Problem 2: Protocol difference of micro services
Problem 3: Tigthly coupled client and services
tomorrow if we split the application in to 2 services then client code has to change
- Performance issues Even a single page of your app may need multiple calls for different microservices, which may lead to large latency and performance issues.
- Scalability issues Because the client app directly references microservices, just about any change to the microservices can cause the app to break. This makes maintenance difficult.
Clients or distinct business domains should rather consider using the Backend for Frontend pattern from the start.
2. API GATEWAY
There comes API gateway a entry point to microservices
Parallel calls when composing the APIs, infact you can write how ever you want serial + parallel
- Authentication
Most gateways perform some sort of authentication for each request (or series of requests). According to rules that are specific to each service, the gateway either routes the request to the requested microservice(s) or returns an error code (or less information). Most gateways add authentication information to the request when passing it to the microservice behind them. This allows microservices to implement user specific logic whenever required.
2. Security SSL termination
Many gateways function as a single entry point for a public API. In such cases, the gateways handle transport security and then dispatch the requests either by using a different secure channel or by removing security constraints that are not necessary inside the internal network. For instance, for a RESTful HTTP API, a gateway may perform "SSL termination": a secure SSL connection is established between the clients and the gateway, and proxied requests are then sent over non-SSL connections to internal services
3. Load-balancing
Under high-load scenarios, gateways can distribute requests among microservice-instances according to custom logic. Each service may have specific scaling limitations. Gateways are designed to balance the load by taking these limitations into account. For instance, some services may scale by having multiple instances running under different internal endpoints. Gateways can dispatch requests to these endpoints (or even request the dynamic instantiation of more endpoints) to handle load.
3. Backend for Frontend
BFF is essentially a variant of the API Gateway pattern. It also provides an additional layer between microservices and clients. But rather than a single point of entry, it introduces multiple gateways for each client.
With BFF, you can add an API tailored to the needs of each client, removing a lot of the bloat caused by keeping it all in one place. The result pattern can be seen in the picture below.
It's worth it to mention that this particular pattern may still be extended for particularly complex apps. Different gateways can also be created for particular business domains. This model is flexible enough to respond to just about any type of microservices-based situation.
Does it mean that each microservices-based architecture should use the BFF pattern? Not necessarily. The more complex design, the more setup and configuration it requires. Not every app may require that. But if you want to create an ecosystem of apps, or plan to extend it in the future, you may choose a more complex communication pattern for the sake of future scalability.