Here’s a Lovely Dress to Understand API Gateway With Golang
Let’s learn API Gateways
Wow, such a lovely dress! While surfing the web, it is almost impossible not to see commercials for beautiful dresses if we searched before. However, what can happen when we click over these dress commercials? We are directed to the shopping site and see all details of this dress. Are these details coming from the same service, or are they aggregated and sent to us? Today, I will talk about the second option, which is API Gateways.
What are the API Gateways?
An API gateway handles all API calls from clients by routing them to the appropriate microservice and invokes these microservices and aggregates the results. The API gateway hides internal APIs from its clients. If there is any failure in the microservices, the API gateway can mask them by returning cached or default data. It simplifies both the client implementation and the microservices app because it is an entry point for every request coming from the client.
Overview of Project
Our clients click our lovely dress to see it with more detail. When they click it, they can see its id, name, description, stock, and price. However, there is no such service that can provide all these details. These details come from different services. We need to aggregate these pieces of information and send them to our clients. We need a hero to do that. At that point, the API gateway comes to light.
When the clients want to see our beautiful dress, they send a request to the gateway, which has products/:id endpoint. To aggregate all these details, the gateway sends a request to our backend microservices which have different endpoints. Our client should have sent the request to these microservices if there is no gateway.
Dive into API Gateway
Our hero should make three API calls to aggregate these pieces of information. From an efficiency point of view, it would be much wiser to run as many calls concurrently as possible. She wants to respond all clients who ask to see details of the dress. Although she cannot be everywhere simultaneously, she can fly very fast to aggregate all data. She needs to reduce overall waiting time. This is why we’re helping her with goroutines.
We have more than one goroutine because we have three API calls. Our hero is busy, so she needs to know when her job is done. Therefore, we’re waiting for three goroutines to be done, then send aggregated data to the client.
Bonus: BFF
Assume that you have both mobile service and web service, which means you have different UIs, and you know that the nature of a mobile experience often differentiates drastically from a desktop web experience. Do you prefer to provide a single API for each kind of client or provide one API per client?
What do we mean by differentiating? Mobile devices need to make fewer calls for the goodness of their battery life and need to display different data when comparing desktop counterparts. Therefore, both user interfaces need to be supported by different APIs with unique functionality instead of one general API.
You may have heard downstream and upstream services before. These terms are used to describe the direction of the chain of dependent service requests.
A downstream service initiates requests and receives responses.
An upstream service receives requests and returns responses.
For more details about BFF, you read this article.
Source Code
https://github.com/dilaragorum/lovely-dress-go
Thank you for reading this far. I try to keep my project simple to focus on the main concept, which is the API gateway. I will be happy if you have any recommendations and feedback.
Here’s the link to my previous articles:
