Edition 0 Updated to asp. Net core 0

Issues with direct client-to-microservice communication
. When the application is large, with 
dozens of microservices, there are challenges and limitations if the application requires direct client-
to-microservice communications. One problem is a potential mismatch between the needs of the 
client and the APIs exposed by each of the microservices. In certain cases, the client application might 
need to make many separate requests to compose the UI, which can be inefficient over the Internet 
and would be impractical over a mobile network. Therefore, requests from the client application to the 
back-end system should be minimized. 
Another problem with direct client-to-microservice communications is that some microservices might 
be using protocols that are not Web-friendly. One service might use a binary protocol, while another 
service might use AMQP messaging. Those protocols are not firewall-friendly and are best used 
internally. Usually, an application should use protocols such as HTTP and WebSockets for 
communication outside of the firewall. 

---

99 
CHAPTER 5 | Designing and Developing Multi-Container and Microservice-Based .NET Applications 
Yet another drawback with this direct client-to-service approach is that it makes it difficult to refactor 
the contracts for those microservices. Over time developers might want to change how the system is 
partitioned into services. For example, they might merge two services or split a service into two or 
more services. However, if clients communicate directly with the services, performing this kind of 
refactoring can break compatibility with client apps. 
As mentioned in the architecture section, when designing and building a complex application based 
on microservices, you might consider the use of multiple fine-grained API Gateways instead of the 
simpler direct client-to-microservice communication approach.