Eshoponcontainers: Why the API Gateway communicates directly with microservices without going through the event bus?

[Hp93]

Hi, I'm learning microservice architecture through the ebook, I have a question about the architecture, not the code. Not sure if I should ask it here?

As I understand, API Gateways connect directly with each microservices using HTTP (gRPC or REST), without going through the Even Bus.
I can think of some issues with this approach:

• API gateways need to know about the microservices and where they are located (server, IP address, port...).
• We need to set up a load balancer if we want to run more instances of a microservice.
• Lacking feature that Event Bus support like message queue...

So I wonder if we already have an event bus, why don't use it, and why the event bus is only used between microservices?

There are also some features that I think are missing from the event bus (rabbitMQ):

• Process multiple requests (messages) in parallel to utilize resources (like web API): could this be solved by running more instances?
• Request/response pattern: this can be implemented using temporary queues to wait for responses.

[sughosneo]

Hi @Hp93, thank you for reaching out.

Yes, eShopOnContainers is the reference application for the eBook .NET microservices - Architecture e-book

EventBus is been used to implement asynchronous event-driven communication among different microservices. RabbitMQ has been used as a choice of event bus to keep the implementation simple. But for production scenario you may want to use managed services like Azure Event Bus. You can refer Asynchronous-messaging for more details. And you can read the implementation specific details in here

Whereas the purpose of having an API Gateway pattern is to provide the specific backend for frontends For e.g BFF-Implementation
Apart from supporting basic routing between clients and individual microservices, API gateway also helps in providing many advance features like compositions of the granular microservices API call, rate-limiting, authorization etc..
It also can be seen a uniform layer for the client for interacting to different microservices in a similar manner irrespective of how it has actually been implemented internally or even ignoring the fact of which specific communication protocol that microservice supports. Initially Ocelot had been used as an API gateway but later that has been replaced with Envoy service proxy. But that architecture point of view there is not much of a difference.
API gateway is more like a pattern and it doesn't emit any event or consume any messages of it's own to make pub-sub communication happen through the event bus. If you refer the architecture of eShopOnContainers you would notice
each microservice has it's own API gateway where they get registered in API Gateway with the name rather with hard coded ip address and port. So that the service gets discoverable internally through it's name both in local or production scenario.

Further references :

The API gateway pattern versus the Direct client-to-microservice communication

Implement API Gateways with Ocelot

Hope this helps !

[sughosneo]

Hi @Hp93, Considering the original questions have been answered, I am closing this issue as of now.
If you have any further questions, please feel free to reopen it.

Thank you.