Vemos cada vez m¨¢s y m¨¢s herramientas, como , 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 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 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.
