Pattern: Back ends for front ends
samnewman.io
samnewman.io
However, this approach is a giant pain in the ass and technologies like Falcor (netflix cannabilizing its own pattern) and (my preference) GraphQL will come to replace.
With a generic client side query language, you don't need to deal with versioning APIs, lots of concurrent development, overhead of deploying a new API for each client, the list goes on. GraphQL in front of a set of services is how we're approaching our next project and it's working really well so far.
The alternative in a GraphQL world would be to have a set of best-practices which annotate the data model. So a backend engineer would write a piece of documentation saying : "Warning: consider avoiding [field2] for significant performance gains".
How is this different in essence from an annotation?
It's also worth noting if you want to have guarantees that your front end engineer doesn't fuck up your performance terribly by making bad queries without them being analyzed or whatever, you can take the stored query approach (this is what facebook does - also good for preventing accidental data leaks) where you store each usable graphql query in a database, and hardcode the query's ID into your application rather than the query itself.
In today's front-end technologies with webpack and webcomponents why wouldn't you compose application that call different services and compose the UI based on these services.
For example, you have a login/welcome component that will call the auth service and will check if the user is logged in or not and show the appropriate message or login screen. If the Auth service is down you can simply show a message.
This way, each component is aware of the service it has to use and you can package it into the application deployment process.
It's worth a thought that if you already have micro-services you should also break your application apart and not have a monolithic front-end.
I am not an Android/iOS guy so I'm not sure if this is even viable there but these days, I'm pretty sure we'll start seeing front-ends that are composed around small single-responsibility services.
One of the biggest advantages of that is that components and services are independent, you can split the work between teams and the application deployment will join everything together.
But generally wouldn't you just add the APIs into the core microservice to return the requested dataset (at the various necessary "levels" of cardinality) for the various different consumers? Keeps everything in one place.
Then you use nginx lua script to allow a single HTTP request from the client to be dispatched to the various microservices and packaged together in the reply in a singel round-trip. This can be just a few lines of code serving any combination of possible sub-requests. I don't like the idea at all of building another service layer on the backend to do the aggregation and expose a different API... I think you can do something similar in the development branch of HAProxy.