I\'m trying to understand where GraphQL is most suitable to use within a Microservice architecture.
There is some debate about having only 1 GraphQL schema that works as
To question 1, Intuit acknowledged the power of GraphQL few years back when it announced moving to One Intuit API ecosystem (https://www.slideshare.net/IntuitDeveloper/building-the-next-generation-of-quickbooks-app-integrations-quickbooks-connect-2017). Intuit chose to go with approach 1. The drawback that you mention actually prevents developers from introducing breaking schema changes that could potentially disrupt client applications.
GraphQL has helped improve productivity of developers in a number of ways.
GraphQL has helped client applications become simpler and faster. Want to retrieve data from /update data to multiple microservices? All client applications have to do is fire ONE GraphQL request and the API Gateway abstraction layer will take care to fetch and collate data from multiple sources (microservices). Open source frameworks like Apollo (https://www.apollographql.com/) have accelerated the pace of GraphQL adoption.
With mobile being the first choice for modern applications, it is important to design for lower data bandwidth requirements from ground zero. GraphQL helps by allowing client apps to request for specific fields only.
To question 2: We built a custom abstraction layer at the API Gateway that knows which part of the schema is owned by which service (provider). When a query request arrives, the abstraction layer forwards the request to the appropriate service(s). Once the underlying service returns the response, the abstraction layer is responsible to return the requested fields.
However, today there are several platforms out there (Apollo server, graphql-yoga, etc.) that allow one to build a GraphQL abstraction layer in no time.