Usar GraphQL em seu aplicativo front-end é como jogar um jogo de bola diferente do que usar REST. Bibliotecas cliente, como urql , Cliente Apollo e Relay podem oferecer recursos diferentes das bibliotecas REST, como Axios ou fetch .
Por quê? Porque GraphQL é uma especificação de API opinativa em que tanto o servidor quanto o cliente compram em um formato de esquema e formato de consulta . Com base nisso, eles podem fornecer vários recursos avançados, como utilitários para armazenamento de dados em cache, geração automática de React Hooks com base em operações e mutações otimistas.
Às vezes, as bibliotecas podem ser muito opinativas e oferecem muita “mágica”. Eu uso o Apollo Client há algum tempo e fiquei frustrado com seus mecanismos de cache e de estado local.
Esse “inchaço”, junto com o recente fato de ver como a comunidade de código aberto é mal administrada, finalmente quebrou a cabeça para mim. Percebi que precisava procurar em outro lugar por uma biblioteca cliente GraphQL.
O que é urql?
Insira urql, que é uma ótima alternativa. Não é o novo garoto do bloco-existe desde 2019-, mas acabei de fazer a mudança e mantenho minha decisão.
A maior parte da linguagem é a mesma que Cliente Apollo , que tornou a troca do Apollo para o urql bastante simples. O urql tem muitos dos mesmos recursos, mas também oferece melhorias, incluindo melhor documentação, melhores padrões de configuração e suporte primário para coisas como modo offline, uploads de arquivos, fluxos de autenticação e um plugin Next.js primário.
Ao empilhar o Apollo Client e o urql um contra o outro, você começará a se perguntar por que o Apollo Client se tornou tão popular.
Tchau Cliente Apollo 
, olá urql
Enquanto escrevo isso, o problema do repositório Github do cliente Apollo a contagem é de 795. Em comparação, urql tem 16 . “Mas a contagem de problemas não se correlaciona com a qualidade do código!” é o que você pode me dizer. Isso é verdade, mas dá a você a mesma sensação de um cheiro de código-você sabe que algo não está certo.
Olhando mais a fundo, você pode ver uma grande quantidade de problemas abertos, bugs que levam meses para consertar e solicitações pull nunca parecem ser mescladas de colaboradores externos. A Apollo parece não estar focada em construir o grande pacote de cliente que a comunidade deseja.
Esse tipo de comportamento indica para mim que a Apollo está usando código aberto apenas para marketing e não para tornar seu produto melhor. A empresa quer que você se familiarize com o Apollo Client e, em seguida, compre seus produtos, e não um software verdadeiramente de código aberto, na minha opinião. Este é um dos negativos de o modelo de negócios de núcleo aberto .
Comecei a procurar em outro lugar por um cliente GraphQL que tivesse uma comunidade mais feliz e coesa. Quando uma ferramenta é bem projetada e com recursos que a comunidade deseja, menos problemas são criados e há menos necessidade de solicitações pull. Formidable é a agência por trás do urql, e eles se preocupam em criar aplicativos de maneira rápida e sustentável, em comparação com tentando direcionar os usuários para que usem seus produtos.
Por que usar o urql?
Para mim, urql é uma lufada de ar fresco depois de trabalhar com o Apollo Client por tanto tempo. Existem muitas pequenas coisas que contribuem para uma experiência do desenvolvedor muito melhor, especialmente para os novatos. Aqui estão apenas alguns.
A documentação em urql é completa
Ter uma boa documentação é um recurso chave para qualquer biblioteca de código aberto. Sem ótimos documentos, haverá mais confusão entre a comunidade sobre como usá-lo e como funciona internamente. Atribuo urql’s minuciosamente docs a razão pela qual tem uma contagem de problemas tão baixa. Levei apenas algumas horas para ler a documentação inteira .
Isso é impressionante porque mostra como a biblioteca é focada e como sua estrutura é bem planejada. Alguns dos destaques incluem este one-pager sobre a arquitetura de como urql funciona e esta tabela comparando-se a outros clientes GraphQL ( como Apollo) .
Plug-ins e pacotes têm suporte próprio no urql
O urql realmente chamou minha atenção quando soube que tinha suporte de primeira classe para funcionalidades adicionais, como modo offline , uploads de arquivo , autenticação e Next.js . Todos esses são recursos que sempre considerei básicos para um cliente GraphQL, e é ótimo ver que o urql tem suporte de primeira parte para eles.
Por exemplo, o pacote de troca de autenticação urql você implementou apenas alguns métodos para ter um fluxo de autenticação completo em seu cliente, incluindo a lógica de atualização de token. Você pode conseguir todas essas coisas no Apollo Client, mas não existem documentos ou pacotes oficiais. Isso significa que você gasta mais tempo pesquisando soluções, hacks e códigos da comunidade.
//Todo o código necessário para suportar o modo offline no urql
import {createClient} de'urql';
importar {offlineExchange} de'@ urql/exchange-graphcache';
importar {makeDefaultStorage} de'@ urql/exchange-graphcache/default-storage'; const storage=makeDefaultStorage ({ idbName:'apiCache', maxAge: 7,//A idade máxima dos dados persistentes em dias
}); const cache=offlineExchange ({ esquema, armazenar, atualizações: { /*... */ }, otimista: { /*... */ },
}); const client=createClient ({ url:'http://localhost: 3000/graphql', trocas: [cache]
});
Também é ótimo que eu não tive que desistir de coisas que eu amava quando trabalhava com o Apollo Client, como as ferramentas de desenvolvimento e a geração de ganchos React porque o urql tem um extensão do navegador de ferramentas dev e um plugin para gerador de código gráfico .
Armazenar em cache em urql é fácil e eficaz
Há um lema comum do desenvolvedor de que a invalidação de cache é uma das coisas mais difíceis na programação. Depois de muitas horas depurando o cache normalizado dos clientes Apollo, eu acredito. Os padrões de cache do urql são sensíveis ao recém-chegado e podem ser estendidos para se tornarem mais avançados.
Agradeço que isso não o force a usar um cache normalizado por padrão, mas vem com um cache de documentos . Isso funciona apenas com o hash da consulta e de suas variáveis -é simples e eficaz!
Aprender como um armazenamento em cache complexo e totalmente normalizado funciona apenas para começar a usar uma biblioteca cliente parece uma tarefa difícil. Apenas oferecer cache normalizado é algo que achei que o Apollo Client errou.
Existe uma curva de aprendizado íngreme para gerenciar um cache normalizado e é desnecessário para muitos aplicativos. É fantástico que o urql ofereça isso como um pacote separado que você pode ativar posteriormente. Já vi essa tendência ser demonstrada com outros pacotes, como React Query .
Embora a grande maioria dos usuários não precise de um cache normalizado, nem mesmo se beneficie dele tanto quanto acreditam.- React Query Docs
importar {ApolloClient, InMemoryCache} de'@ apollo/client'; const client=new ApolloClient ({ uri:"http://localhost: 4000/graphql", //O cache normalizado é necessário cache: novo InMemoryCache ()
}); import {createClient} de"urql"; //Cache de documentos habilitado por padrão
export const client=createClient ({ url:"http://localhost: 4000/graphql",
});
O estado local é simplificado no urql
urql permanece fiel aos dados do servidor e não fornece funções para gerenciar o estado local como o Apollo Client faz. Na minha opinião, isso é perfeitamente normal, já que bibliotecas completas para gerenciar o estado local no React estão se tornando menos necessárias. Misturar o estado do lado do servidor e o estado local parece ideal a princípio (um lugar para todos os estados), mas pode levar a problemas quando você precisa descobrir quais dados são novos e quais estão desatualizados e quando atualizá-los.
React Context é uma ótima solução para situações em que você tem muitos perfuração de suporte em andamento, que às vezes é o principal motivo pelo qual as pessoas procuram uma biblioteca local de gestão estadual. Eu também recomendaria XState se você estiver procurando uma maneira de gerenciar fluxos de trabalho com estado, que às vezes as pessoas usam Redux redutores para.
Comportamento padrão compreensível com trocas
Trocas são semelhantes a links no Apollo Client e oferecem maneiras de estender a funcionalidade do cliente por meio da interceptação de solicitações. A diferença com o urql é que você pode optar até mesmo pelos básicos, permitindo mais controle e compreensão sobre o comportamento do cliente.
Ao começar , o cliente não tem trocas obrigatórias e usa uma lista padrão. Na minha experiência, começar com apenas algumas trocas e adicionar mais conforme o tempo passava ou quando eu precisava delas tornava a depuração mais fácil. urql mostra que leva a extensibilidade a sério no suporte a muitos casos de uso diferentes.
Aqui está um exemplo das trocas que você pode usar depois de se acostumar com o urql:
import {createClient, dedupExchange, cacheExchange, fetchExchange} de'urql'; const client=createClient ({ url:'http://localhost: 4000/graphql', trocas: [ //elimina a duplicação de solicitações se enviarmos as mesmas consultas duas vezes dedupExchange, //do exemplo anterior cacheExchange, //responsável por enviar nossas solicitações para nossa API GraphQL fetchExchange, ],
});
uqrl oferece um plugin de suporte Next.js
Next.js é uma das formas mais populares de usar o React atualmente. Integrar o Apollo Client para usar o SSR Next.js no passado sempre foi uma grande dor. Com cada atualização, você terá que procurar exemplos e provavelmente precisará mudar a forma como ele funciona.
Sem nenhum plugin oficial do Apollo, você terá que manter essa integração. Conforme mencionado anteriormente, o urql possui um plugin oficial para Next.js. Isso facilita a integração.
//Componente Simple React integrando-se com Next.js usando o plugin
import React from'react';
import Head from'next/head';
importar {withUrqlClient} de'next-urql'; importar PokemonList de'../components/pokemon_list';
importar PokemonTypes de'../components/pokemon_types'; Const Root=()=> ( Root
Conclusão
O urql tem vantagens sobre o Apollo Client quando se trata de sua comunidade unificada, ótima documentação e plug-ins originais e sistema de cache. Gosto especialmente de como eles parecem estar trabalhando e se envolvendo com a comunidade, em vez de contra ela.
Tenho tentado muitos clientes GraphQL ultimamente para ver o que mais existe para compará-los ao Apollo e foi revigorante ver como o urql é ótimo. Eu me prevejo usá-lo daqui para frente para todos os meus aplicativos GraphQL. Espero que isso o leve a experimentar o urql por si mesmo e ver o que você acha. Obrigado por ler!
A postagem Por que eu (finalmente) alterado para urql do Apollo Client apareceu primeiro no LogRocket Blog .
