Question about eShopOnContainers api gateway route prefix

0
votes

There is project called eShopOnContainer, it's a .NET Microservices Sample Reference Aplication, powered by Microsoft, based on a simplified microservices architecture and Docker containers.

They are using Envoy as a reverse proxy on API Gateway, you can see more about it here. The Envoy is configured with the following rules:

  • Routes with prefix "/c/" forwards to "/catalog-api/" (Catalog microservice)
  • Routes with prefix "/o/" forwards to "/ordering-api/" (Order microservice)
  • Routes with prefix "/b/" forwards to "/basket-api/" (Basket microservice)

This application has an eBook that explain many decisions taken, there is a section where they talk about this topic: Why consider API Gateways instead of direct client-to-microservice communication and this is one of the reasons:

Coupling: Without the API Gateway pattern, the client apps are coupled to the internal microservices. The client apps need to know how the multiple areas of the application are decomposed in microservices. When evolving and refactoring the internal microservices, those actions impact maintenance because they cause breaking changes to the client apps due to the direct reference to the internal microservices from the client apps. Client apps need to be updated frequently, making the solution harder to evolve.

So I was thinking, the fact of using a prefix on the route generete a problem: "The client apps need to know how the multiple areas of the application are decomposed in microservices", right? So is it an anti-pattern?

1
c#.netmicroservicesapi-gateway

1 Answers

0
votes

regardless of microservices architecture or monolith architecture, this statement always stay true

The client apps need to know how the multiple areas of the application are decomposed in microservices

With typical monolith application, you'll have to config the application routing in your application business logic, either with route prefix, or route area

Now, with api gateway and microservices architecture, you'll achieve a few things as below

  • your application only expose small set of APIs
  • the routing will be configured in the network infra layer (host/a/api/... route to a-service), often combine with multiple middlewares (for example: strip the /a/ prefix from the origin url, ip whitelisting, audit, authn & authz, etc)
  • better observability with lots of paid & free tools
  • the service can be replaced/swapped quite easily
  • complex routing with blue/green and/or canary deployments, possibly with automated traffic testing & service promotion
  • and more....