Temos visto muitas implementa??es bem-sucedidas com 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 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 , a JavaScript framework that was designed to support the React.js stateless component model.
