Microservices.io is brought to you by Chris Richardson. Experienced software architect, author of POJOs in Action and the creator of the original CloudFoundry.com. His latest startup is eventuate.io, a microservices application platform.
Chris offers a comprehensive set of resources for learning about microservices including articles, an O'Reilly training video, and example code. Learn more
Chris offers a comprehensive consulting services, workshops and hands on training classes to help you use microservices effectively. Get advice
I'll be there in May! Contact me
Want to see an example? Check out Chris Richardson's example applications. See code
Cross cutting concerns
Join the microservices google group
Let’s imagine you are building an online store that uses the Microservice architecture pattern and that you are implementing the product details page. You need to develop multiple versions of the product details user interface:
In addition, the online store must expose product details via a REST API for use by 3rd party applications.
A product details UI can display a lot of information about a product. For example, the Amazon.com details page for POJOs in Action displays:
Since the online store uses the Microservice architecture pattern the product details data is spread over multiple services. For example,
Consequently, the code that displays the product details needs to fetch information from all of these services.
How do the clients of a Microservices-based application access the individual services?
The granularity of APIs provided by microservices is often different than what a client needs. Microservices typically provide fine-grained APIs, which means that clients need to interact with multiple services. For example, as described above, a client needing the details for a product needs to fetch data from numerous services.
Different clients need different data. For example, the desktop browser version of a product details page desktop is typically more elaborate then the mobile version.
Network performance is different for different types of clients. For example, a mobile network is typically much slower and has much higher latency than a non-mobile network. And, of course, any WAN is much slower than a LAN. This means that a native mobile client uses a network that has very difference performance characteristics than a LAN used by a server-side web application. The server-side web application can make multiple requests to backend services without impacting the user experience where as a mobile client can only make a few.
The number of service instances and their locations (host+port) changes dynamically
Partitioning into services can change over time and should be hidden from clients
Implement an API gateway that is the single entry point for all clients. The API gateway handles requests in one of two ways. Some requests are simply proxied/routed to the appropriate service. It handles other requests by fanning out to multiple services.
Rather than provide a one-size-fits-all style API, the API gateway can expose a different API for each client. For example, the Netflix API gateway runs client-specific adapter code that provides each client with an API that’s best suited to it’s requirements.
The API gateway might also implement security, e.g. verify that the client is authorized to perform the request
A variation of this pattern is the Backend for Front-End pattern. It defines a separate API gateway for each kind of client.
In this example, there are three kinds of clients: web application, mobile application, and external 3rd party application. There are three different API gateways. Each one is provides an API for it’s client.
Using an API gateway has the following benefits:
The API gateway pattern has some drawbacks: