Hemos visto muchas implementaciones exitosas de GraphQL en nuestros proyectos. También hemos visto algunos patrones de uso interesantes, incluyendo GraphQL for server-side resource aggregation. Dicho esto, existen inquietudes sobre el mal uso de este framework y algunos de los problemas que pueden ocurrir. Por ejemplo problemas de rendimiento alrededor de consultas N+1 y código repetitivo necesario cuando se agregan nuevos modelos, conduciendo a complejidad. Hay alternativas a estos problemas como el cacheo de consultas. Sin embargo, no es una “bala de plata”, todavía pensamos que vale la pena una evaluación como parte de tu arquitectura.
When we look at REST implementations in the wild, we frequently see REST misused to naively retrieve object graphs through chatty interactions between client and server. Facebook's GraphQL is an interesting alternative to REST that might be a better approach for this very common use case. As a protocol for remotely retrieving object graphs, GraphQL has received enormous attention recently. One of GraphQL's most interesting features is its consumer-oriented nature: The structure of a response is driven entirely by the client, not the server. This decouples the consumer and forces the server to obey Postel's law. Client implementations are now available in many programming languages, but we have seen a flurry of interest of Facebook's Relay, a JavaScript framework that was designed to support the React.js stateless component model.
