Existem desvantagens no GraphQL? [fechadas]

Todos os artigos sobre GraphQL dirão como ele é maravilhoso, mas há alguma desvantagem ou deficiência nele? Obrigado.

Desvantagens:

• Você precisa aprender a configurar o GraphQL. O ecossistema ainda está evoluindo rapidamente, então você precisa acompanhá-lo.
• Você precisa enviar as consultas do cliente, você pode apenas enviar strings, mas se quiser mais conforto e armazenamento em cache, você usará uma biblioteca cliente -> código extra em seu cliente
• Você precisa definir o esquema de antemão => trabalho extra antes de obter os resultados
• Você precisa ter um endpoint Graphql em seu servidor => novas bibliotecas que você ainda não conhece
• As consultas Graphql têm mais bytes do que simplesmente ir para um endpoint REST
• O servidor precisa fazer mais processamento para analisar a consulta e verificar os parâmetros

Mas, esses são mais do que contrariados por estes:

• GraphQL não é tão difícil de aprender
• O código extra tem apenas alguns KB
• Ao definir um esquema, você evitará muito mais trabalho depois de corrigir bugs e resistir a atualizações complicadas
• Há muitas pessoas mudando para GraphQL, então há um rico ecossistema em desenvolvimento, com ferramentas excelentes
• Ao usar consultas persistentes na produção (substituindo consultas GraphQL por simplesmente um ID e parâmetros), você realmente envia menos bytes do que com REST
• O processamento extra para consultas recebidas é insignificante
• Fornecer uma dissociação limpa de API e back-end permite uma iteração muito mais rápida em melhorias de back-end

Eu encontrei algumas preocupações importantes para qualquer pessoa que esteja considerando usar GraphQL , e até agora os pontos principais são:

Consulta em profundidade indefinida : GraphQL não pode consultar em profundidade indefinida, então se você tem uma árvore e deseja retornar um ramo sem saber a profundidade, você terá que fazer alguma paginação.

Estrutura de resposta específica : No GraphQL, a resposta corresponde ao formato da consulta, portanto, se você precisar responder em uma estrutura muito específica, terá que adicionar uma camada de transformação para remodelar a resposta.

Cache no nível da rede : devido à maneira comum como o GraphQL é usado sobre HTTP (um POST em um único endpoint), o cache no nível da rede torna-se difícil. Uma maneira de resolver isso é usar consultas persistentes.

Manipulando upload de arquivo : Não há nada sobre upload de arquivo na especificação GraphQL e mutações não aceita arquivos nos argumentos. Para resolver isso, você pode fazer upload de arquivos usando outro tipo de APIs (como REST) ​​e passar a URL do arquivo carregado para a mutação GraphQL, ou injetar o arquivo no contexto de execução, para que você tenha o arquivo dentro das funções de resolução.

Execução imprevisível : A natureza do GraphQL é que você pode consultar combinando quaisquer campos que desejar, mas essa flexibilidade não é gratuita. É bom saber algumas preocupações, como Consultas de Desempenho e N + 1.

APIs super simples : no caso de você ter um serviço que expõe uma API realmente simples, GraphQL apenas adicionará uma complexidade extra, portanto, uma API REST simples pode ser melhor.

O maior problema que vejo com o GraphQL ou seja, se você está usando com banco de dados relacional é com joins .

1. O fato de você poder permitir / não permitir alguns campos torna as junções não triviais (não simples). O que leva a consultas extras.

2. Além disso, as consultas aninhadas no graphql levam a consultas circulares e podem travar o servidor . Cuidado extra deve ser tomado.

3. A limitação da taxa de chamadas torna-se difícil porque agora o usuário pode disparar várias consultas em uma chamada.

DICA : Use o dataloader do Facebook para reduzir o número de consultas em caso de javascript / node

Está ficando cada vez melhor a cada ano e, por enquanto, a comunidade do GraphQL está crescendo e, como resultado, há muito mais soluções para muitos problemas que foram destacados em outras respostas antes. Mas, para admitir o que ainda está impedindo as empresas de alocar todos os recursos ao GraphQL, gostaria de listar alguns problemas e soluções seguidos de outros não resolvidos.

• Cache a nível de rede - como o Bruno disse são consultas persistentes e claro que você pode fazer cache em um cliente e ninguém te impede de usar o cache em nível de banco de dados ou mesmo Redis. Mas é claro, como o GraphQL tem apenas um ponto de extremidade e cada consulta é diferente - é muito mais complicado fazer esse tipo de cache do que com REST.
• As consultas aninhadas no GraphQL levam a consultas circulares e podem travar o servidor - não é mais um problema com uma grande variedade de soluções. Alguns deles estão listados aqui
• Manipulação Carregar Arquivo - já temos lotes de soluções para ele

Mas existem mais alguns casos que podem ser considerados desvantagens:

• excesso de clichê (com isso, quero dizer, para a criação, por exemplo, de uma nova consulta, você precisa definir o esquema, o resolvedor e dentro do resolvedor para dizer explicitamente ao GraphQL como resolver seus dados e campos internos; no lado do cliente, crie a consulta exatamente com campos relacionados a estes dados)
• tratamento de erros - preciso dizer que está mais relacionado à comparação com REST. É possível aqui com apollo, mas ao mesmo tempo é muito mais complicado do que em REST
• autenticação e autorização - mas como eu disse comunidade está aumentando com velocidade excelente e há já algumas das soluções para esse objetivo.

Para resumir, GraphQL é apenas uma ferramenta para objetivos específicos e com certeza não é uma solução mágica para todos os problemas e, claro, não é um substituto para o REST.

É muito bom ter um único endpoint e expor todos os dados. Encontro abaixo pontos a serem considerados para GraphQL:

1. A implementação de download / upload de arquivo fica complicada (converter em string pode não ser a melhor opção para arquivos grandes)
2. Muito código padrão e de esquema no front-end e no back-end.
3. Siga e suporte a paginação fornecida na especificação GraphQL.
4. Permitir ordenação personalizada e lógica de priorização para ordenação de campos. Exemplo se buscarmos dados de usuários e grupos e funções associados. Um usuário pode classificar os dados com base no nome de usuário, nome do grupo ou nome da função.
5. A autenticação e a autorização seriam dependentes da estrutura de back-end.
6. Certifique-se de que a otimização de back-end e o suporte de banco de dados para disparar uma única consulta para cada comando graphql possam ser complicados.

Além disso, deve-se considerar os Prós após sua implementação:

1. Muito flexível para suportar novos itens e atualizar o comportamento existente.

2. Fácil de adicionar condições usando argumentos e ordenação personalizada, uma vez implementada

3. Use muitos filtros personalizados e se livre de todas as ações que precisam ser criadas, por exemplo, um usuário pode ter id, nome, etc como argumentos e realizar a filtragem. Além disso, os filtros também podem ser aplicados nos grupos dos usuários.

4. Fácil de testar API criando arquivos contendo todas as consultas e mutações GraphQL.
5. As mutações são diretas e fáceis de implementar, uma vez compreendido o conceito.
6. Maneira poderosa de buscar várias profundidades de dados.
7. O suporte do Voyager e GraphiQL UI ou Playground facilita a visualização e o uso.
8. Facilidade de documentação ao definir o esquema com métodos de descrição válidos.

Eu acho que o graphql no momento deve ser parte da arquitetura de backend, para upload de arquivo você ainda atinge uma API regular