Let's first take a look at the limitations of the client-to-microservice approach:

• Network discrimination: The client has to call several (sometimes hundreds) of microservices in order to render a page. This is possible with a LAN, but in the case of a public network, it could become inefficient. It would also be very difficult when using a mobile network.
• Complex client code: For this approach, we have to write code for numerous REST calls for many microservices, making the client code much more complex.
• Protocol diversity: Some clients might use protocols that are not web-friendly. Suppose one microservice is using Apache Thrift's binary RPC and another is using gRPC or the AMQP messaging protocol. None of these protocols are web-friendly, so a browser cannot use them properly. An application should use protocols such as HTTP and WebSocket outside a firewall.
• Refactoring microservices: Further enhancement of services (such as merging two services or splitting a service into two or more) is extremely difficult because an application's client interacts directly with the services.

Due to these limitations, we never recommend that a client application takes a direct approach when using microservices. This is especially the case when serving an external client application; in such a case, we have to provide a common interface service to the client, such as Facade design, to interact with all microservices. In the next section, we will discuss how to use an API gateway as an alternative.