Esquemas remotos para bancos de dados: junte a saída de qualquer fonte de dados da API GraphQL a um modelo de dados
Embora o objetivo do GraphQL no início fosse fornecer uma especificação para automatizar a composição da API em UIs e criar um contrato cliente-servidor de tipo seguro sobre JSON, seu sucesso vai muito além disso. Indiscutivelmente, e para a frustração dos verdadeiros padrões do GraphQL, os fragmentos do GraphQL e o relay style GraphQL não são tão populares quanto deveriam ser. Isso ocorre porque o GraphQL resolveu um problema muito maior do que apenas automatizar as partes tediosas da composição e integração da API na IU.
Consumo de autoatendimento: os consumidores de API podem navegar, explorar, testar e integrar APIs com um ciclo de feedback muito mais restrito, sem exigir o tipo típico de documentação e ferramentas escritas à mão.
Consulte o que quiser : os consumidores de API podem criar uma consulta de API para obter precisamente os dados que desejam, sem exigir que humanos criem pontos de extremidade personalizados para sua forma de dados favorita. Imagine um banco de dados que forneça dados apenas em uma forma fixa - isso é ridículo! E agora é isso que queremos, mas de nossas APIs também. Desempenho, cache, segurança, etc., devem funcionar tanto quanto possível.
A falta de ferramentas do fornecedor GraphQL em torno do GraphQL na produção - ops, armazenamento em cache, monitoramento, relatórios de erros e QoS, autorização e segurança são todos inteiramente novos no GraphQL. Em cenários de missão crítica, especialmente em ambientes empresariais, o custo da adoção do GraphQL pode ser simplesmente muito alto.