Cloud Bits: API Gateways – Cloud System’s Reception Desk
API gateways are probably one of the first few keywords you hear when you enter the world of cloud computing. You must have yourself or seen someone drop a box casually in a system design interview & mark it as API gateway. Though aside from the fact that it is considered as standard solution for allowing clients to interface with your services, it serves a bunch of other functionalities. Covering all of them will require a post about each of these functionalities(maybe these go into my to-do for future posts). So I will cover two aspects of API gateways in this post i.e. request routing & authentication. This also fits nicely into the theme of the image used in the post which gives you vibes from the Severance.
Lets first go through a brief introduction to API gateway & why we essentially need them. So consider your application which was initially built as a monolith. Now you are bumping into scaling challenges & you decide to jump on the microservice bandwagon(Not always the right choice but you-do-you). Earlier in the monolith all your endpoints were secured through JWT & clients initially called a /login endpoint to get the JWT & then use it in their Authorization headers to invoke service endpoints. The service controllers can make a function call to validate function & verify if JWT is still valid before processing the request.
Now that you are in the microservice world, the request enters your service boundary & then each service will need to invoke the user-service to validate their tokens. This means any change in user-service ends up propagating to all your services. Another challenge is request routing. Earlier your monolith application served all your endpoints whereas in microservice setup, each service serves a set of endpoints. Clients will now need to know which service serves what set of endpoints & where these services(or their corresponding load balancers) are deployed.
