Vemos mais e mais ferramentas como Apollo Federation, que pode agregar vários endpoints do GraphQL em um único grafo. No entanto, advertimos contra o uso indevido do GraphQL, especialmente ao transformá-lo em um protocolo de servidor para servidor. Nossa prática é usar GraphQL para agregação de recursos do lado do servidor apenas. Ao usar esse padrão, os microsserviços continuam a expor APIs RESTful bem definidas, enquanto serviços agregados ocultos ou BFF (Backend for Frontends) usam os resolvedores GraphQL como a implementação para combinar recursos de outros serviços. A forma do grafo é orientada por exercícios de modelagem de domínio para garantir que a linguagem onipresente seja limitada a subgrafos quando necessário (no caso de "um microsserviço por bounded context"). Essa técnica simplifica a implementação interna de serviços agregados ou BFFs, incentivando uma boa modelagem de serviços para evitar REST anêmico.
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.
