Edition 0 Updated to asp. Net core 0

Direct client-to-microservice communication 
A possible approach is to use a direct client-to-microservice communication architecture. In this 
approach, a client app can make requests directly to some of the microservices, as shown in Figure 4-
12. 
Figure 4-12. Using a direct client-to-microservice communication architecture 
In this approach, each microservice has a public endpoint, sometimes with a different TCP port for 
each microservice. An example of a URL for a particular service could be the following URL in Azure: 
http://eshoponcontainers.westus.cloudapp.azure.com:88/
In a production environment based on a cluster, that URL would map to the load balancer used in the 
cluster, which in turn distributes the requests across the microservices. In production environments, 
you could have an Application Delivery Controller (ADC) like 
Azure Application Gateway
 between your 
microservices and the Internet. This layer acts as a transparent tier that not only performs load 
balancing, but secures your services by offering SSL termination. This approach improves the load of 
your hosts by offloading CPU-intensive SSL termination and other routing duties to the Azure 
Application Gateway. In any case, a load balancer and ADC are transparent from a logical application 
architecture point of view. 
A direct client-to-microservice communication architecture could be good enough for a small 
microservice-based application, especially if the client app is a server-side web application like an 
ASP.NET MVC app. However, when you build large and complex microservice-based applications (for 
example, when handling dozens of microservice types), and especially when the client apps are 
remote mobile apps or SPA web applications, that approach faces a few issues. 
Consider the following questions when developing a large application based on microservices: 

---

41 
CHAPTER 3 | Architecting container and microservice-based applications 
•
How can client apps minimize the number of requests to the back end and reduce chatty 
communication to multiple microservices?
Interacting with multiple microservices to build a single UI screen increases the number of round trips 
across the Internet. This approach increases latency and complexity on the UI side. Ideally, responses 
should be efficiently aggregated in the server side. This approach reduces latency, since multiple 
pieces of data come back in parallel and some UI can show data as soon as it’s ready.
•
How can you handle cross-cutting concerns such as authorization, data transformations, and 
dynamic request dispatching?
Implementing security and cross-cutting concerns like security and authorization on every 
microservice can require significant development effort. A possible approach is to have those services 
within the Docker host or internal cluster to restrict direct access to them from the outside, and to 
implement those cross-cutting concerns in a centralized place, like an API Gateway. 
•
How can client apps communicate with services that use non-Internet-friendly protocols?
Protocols used on the server side (like AMQP or binary protocols) are not supported in client apps. 
Therefore, requests must be performed through protocols like HTTP/HTTPS and translated to the 
other protocols afterwards. A 
man-in-the-middle
approach can help in this situation. 
•
How can you shape a facade especially made for mobile apps?
The API of multiple microservices might not be well designed for the needs of different client 
applications. For instance, the needs of a mobile app might be different than the needs of a web app. 
For mobile apps, you might need to optimize even further so that data responses can be more 
efficient. You might do this functionality by aggregating data from multiple microservices and 
returning a single set of data, and sometimes eliminating any data in the response that isn’t needed 
by the mobile app. And, of course, you might compress that data. Again, a facade or API in between 
the mobile app and the microservices can be convenient for this scenario.