Vemos cada vez más y más herramientas, como Apollo Federation, que pueden agregar múltiples endpoints de GraphQL en un solo grafo. Sin embargo, alertamos contra el mal uso de GraphQL, especialmente cuando se transforma en un protocolo sevidor-a-servidor. Nuestra experiencia es usar solamente GraphQL para agregar recursos del lado del servidor. Cuando se usa este patrón, los microservicios continúan exponiendo APIs RESTful bien definidas mientras que, por detrás, los servicios agregados o el uso del patron BFF (Backend for Frontends) usan los controladores de GraphQL como la implementación para juntar recursos de otros servicios. La composición del grafo está dirigida por ejercicios de modelado del dominio para asegurar que el lenguaje ubicuo se limita a subgrafos solo donde es necesario (en el caso de un microservicio por “bounded context”). Esta técnica simplifica la implementación interna de agregar servicios o BFFs, mientras que fomenta el uso de un buen modelado de los servicios 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.
