Temos visto muitas implementações bem-sucedidas com GraphQL em nossos projetos. Temos vistos também alguns padrões de uso interessantes, incluindo GraphQL para agregação de recursos do lado do servidor. Dito isso, nos preocupamos com o uso equivocado desse framework e alguns dos problemas que podem ocorrer. Exemplos incluem problemas de performance com consultas N+1 e um excesso de código necessário quando adicionamos novos modelos, levando à complexidade. Há maneiras de se contornar esses problemas, como por exemplo o uso de cache de consulta. Mesmo que GraphQL não seja uma solução mágica, ainda achamos que é válido avaliar como parte de sua arquitetura.
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.
