We see more and more tools such as Apollo Federation that can aggregate multiple GraphQL endpoints into a single graph. However, we caution against misusing GraphQL, especially when turning it into a server-to-server protocol. Our practice is to use GraphQL for server-side resource aggregation only. When using this pattern, the microservices continue to expose well-defined RESTful APIs, while under-the-hood aggregate services or BFF (Backend for Frontends) patterns use GraphQL resolvers as the implementation for stitching resources from other services. The shape of the graph is driven by domain-modeling exercises to ensure ubiquitous language is limited to subgraphs where needed (in the case of one-microservice-per-bounded-context). This technique simplifies the internal implementation of aggregate services or BFFs, while encouraging good modeling of services to avoid anemic REST.
One pattern that comes up again and again when building microservice-style architectures is how to handle the aggregation of many resources server-side. In recent years, we've seen the emergence of a number of patterns such as Backend for Frontend (BFF) and tools such as Falcor to address this. Our teams have started using GraphQL for server-side resource aggregation instead. This differs from the usual mode of using GraphQL where clients directly query a GraphQL server. When using this technique, the services continue to expose RESTful APIs but under-the-hood aggregate services use GraphQL resolvers as the implementation for stitching resources from other services. This technique simplifies the internal implementation of aggregate services or BFFs by using GraphQL.
