No, all I've said is that each service should not manipulate data, that it should provide an interface that makes sense within its domain. This is because each service should make no assumptions as to how it will be used by other services. Consumers should be responsible for combining each domain into something usable for what they're doing. I still haven't said anything about a client.
GraphQL is one way of combining domains. Data sources in GraphQL are implemented as "Resolvers" in their lingo. They can be databases, flat files, but commonly in 2017, other services (see my previous post with a link to an explanation of microservice architecture). So basically, GraphQL would make calls to your N internal services on your behalf, put the data together however you set it up in your scheme, and return it. Yet again, I've said nothing about a client.
Now if you think about this, GraphQL's sole purpose is to translate a set of domains into another. So it, in itself, is a microservice with its own domain, which happens to be a transform. Nothing about a client yet.
So let's discuss - what, exactly, is a client? Most people only consider a phone app or web browser as a client. This isn't strictly true and if this is the only way you perceive it, you will end up with anti-patterns. Anything that uses something else is a client. So if GraphQL uses your Customer service in a resolve function to get data, then it is a client. Now, for the sake of clarity, we typically say "consumer" for the generalized terminology, such that "client" can continue to be used for the vernacular web browser.
Now let's talk about the system and data manipulation from the client-side, web browser side. You could make a single call to your GraphQL instance if you'd like. Your other option is to make N calls to your N services if you'd like. Before you say that's bad, be open minded and keep reading. Regardless of which option you choose, you're still doing the exact same thing: do N calls and a transform from the client side. It just so happens that with the GraphQL option, N is just 1 and the transform is just a no-op.
So why would you want to call each individual service from the client side and make multiple calls? Depending on your application, it may be a positive tradeoff due to scaling reasons. Doing it completely from the client side, while it increases network overhead to the client (and possibly CPU/memory overhead on the client, too, if your transform is heavy), it allows you to employ fault tolerant practices, such as a circuit-breaker pattern, graceful degradation, and so on. In applications where partial data may suffice for limited functionality, this architecture would be more reliable than GraphQL since it eliminates a single point of failure. In practice, making N calls over a single call from the client doesn't really increase latency a whole lot since most or all of them can be done in parallel.
If you want a real-world example as to what I'm talking about, read up on how Netflix implements their LoLoMos (list of list of movies) in their clients. All of the data is fetched on the client side using N calls and the client deals with failure in a seamless way, presenting partial data to the user in the case of an outage. Ever wonder why sometimes certain lists of movies ("popular on Netflix," etc) don't show up sometimes, but the rest of Netflix is working just fine? This is why.
So you said new people shouldn't take my advice. I'll say this - my advice is a modern, advanced approach that has made Netflix, Amazon, Google, Uber, eBay, and many other tech companies successful. I'm not that smart; I learned it from them. But if I were interviewing someone who said this is bad, they wouldn't qualify for a senior position. Think what you want. 🙂
