This is how netflix approached api gateways. <a href="http://techblog.netflix.com/2012/07/embracing-differences-inside-netflix.html" rel="nofollow">http://techblog.netflix.com/2012/07/embracing-differences-in...</a><p>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.<p>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.
Or for those wanting to use an already defined pattern: API gateway pattern [1]. Same idea, already identified.<p><a href="http://microservices.io/patterns/apigateway.html" rel="nofollow">http://microservices.io/patterns/apigateway.html</a>
Right now I am working on a talk around this area and an idea came to my mind that I think is worth a discussion here on HN.<p>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.<p>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.<p>This way, each component is aware of the service it has to use and you can package it into the application deployment process.<p>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.<p>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.<p>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.
AKA the BLL or Business Logic Layer? I guess the only reason you would re-write business logic in the presentation layer is because you can't afford the extra round-trips, and it's cheaper than writing an aggregation layer on your backend.<p>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.<p>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.