Introdução ao Hasura GraphQL Engine para APIs dinâmicas com PostgreSQL

Geralmente, nos últimos anos, as APIs REST foram criticadas por serem inflexíveis ao lidar com requisitos tecnológicos em rápida mudança. Em retrospecto, muitos acreditam que o GraphQL foi criado para lidar com essa necessidade de flexibilidade e eficiência adicionais no desenvolvimento de APIs. Assim, mitigando as deficiências das APIs REST. Como resultado da transição do Facebook de aplicativos HTML5 para configurações mais robustas e nativas, o GraphQL aumentou em popularidade e adoção nos últimos cinco anos por um bom motivo. Neste blog, vamos nos aprofundar no fenômeno GraphQL, PostgreSQL e, posteriormente, ter uma introdução completa ao mecanismo Hasura GraphQL. Em um trecho, o relacionamento e o ecossistema Hasura GraphQL engine-PostgreSQL.

GraphQL: uma rebelião do Facebook

Embora muitos acreditem que o GraphQL foi criado como uma rebelião às APIs REST, isso pode estar mais longe da verdade. Ironicamente, ele foi criado para simplesmente atender a uma necessidade interna do Facebook. Originalmente projetado e de código aberto pela equipe do Facebook, o GraphQL é frequentemente confundido com uma tecnologia de banco de dados. Essencialmente, apesar do equívoco, o GraphQL é tecnicamente uma linguagem de consulta para APIs e não para bancos de dados. Consequentemente, reduz a complexidade da construção de APIs, abstraindo todas as solicitações para um único endpoint. Ao contrário das APIs REST tradicionais, o GraphQL é declarativo, o que significa que o que for solicitado é retornado. No entanto, para obter um pouco mais de contexto, precisaremos dar um passo atrás e revisitar as APIs REST.

A Arquitetura REST

Normalmente, as APIs são regras, rotinas ou protocolos que especificam como os componentes de software devem interagir. A Representational State Transfer (REST) ​​é basicamente uma arquitetura de design de API normalmente alavancada na implementação de web services onde tudo é considerado um 'recurso'. Infelizmente, a metodologia RESTful foi consistentemente limitada a lidar com recursos únicos. Portanto, se os dados fossem necessários e fossem provenientes de dois ou mais recursos, por exemplo, postagens e usuários, seriam necessárias várias viagens de ida e volta ao servidor para coletar tudo o que fosse necessário. Além disso, o REST enfrentou problemas com a busca 'over' e 'under'. Tudo isso não era o ideal, especialmente com o surgimento de aplicativos mais orientados a dados que lidam com grandes conjuntos de dados combinando recursos relacionados. O que poderia explicar a situação que o Facebook enfrentou.

Assim, a necessidade de uma arquitetura de API que adotasse uma abordagem mais flexível e progressiva.

A criação de uma alternativa

Alternativamente, o GraphQL não pensa em dados em termos de URLs de recursos, chaves secundárias ou tabelas, mas em termos de um gráfico de objetos e modelos utilizando NSObjects ou JSON. Especificamente, o GraphQL não precisa de endpoints dedicados por caso de uso, pois diferentes recursos e casos de uso podem ser representados em um único “Gráfico”. Usando a linguagem de consulta GraphQL, você pode descrever exatamente como a resposta deve ser, portanto, não são necessárias viagens de ida e volta adicionais ao servidor. Como uma linguagem de consulta da camada de aplicativo, ela foi projetada para interpretar uma string de um servidor/cliente e retornar esses dados em um formato estável, compreensível e previsível. É simplesmente uma ferramenta para consolidar melhor os dados.

Simplicidade, Estabilidade e Eficiência.

A verdade é que nem todos os projetos requerem GraphQL, apesar de seu esquema bem definido, então sabemos com certeza que não vamos sobrecarregar. No entanto, se tivermos um produto corporativo que depende de dados de várias fontes, por exemplo MySQL, Postgres e outras APIs, o GraphQL é a melhor opção. O GraphQL se orgulha da simplicidade, especialmente no que diz respeito à recuperação de dados, pois os dados são coletados em um ponto de extremidade ou chamada comum. Essencialmente, como os clientes obtêm exatamente o que precisam, isso reduz efetivamente o tamanho de cada solicitação feita pelo cliente, resultando em aplicativos de alto desempenho. Como o GraphQL unifica dados que, de outra forma, exigiriam vários endpoints, ele facilita as recuperações repetidas complexas, aumentando assim a eficiência da consulta. Consequentemente, com sua simplicidade vem mais estabilidade de back-end, planejamento, construção, execução e operação contínua ao longo do tempo.

Vantagens do GraphQL

Em poucas palavras, o GraphQL permite a extração de dados com consultas facilmente compreensíveis, permite o desenvolvimento rápido de aplicativos leves e rápidos, pois os dados são acessados ​​mais diretamente do que por meio de um servidor. Além disso, permite a recuperação de vários recursos com uma consulta sem usar vários URLs ou encadeamento de recursos, enquanto usa um endpoint para todos os dados. Lembre-se, os dados são definidos no servidor com um esquema baseado em gráfico, portanto, são entregues como um pacote e não por meio de várias chamadas. Isso permite um impulso operacional na agregação de respostas de API durante o desenvolvimento de API.

Isso, por sua vez, diminui a carga nas equipes de desenvolvimento de front-end, facilita o controle de versão da API, simplifica a manutenção e economiza nas demandas de transferência de dados. Além disso, permite mais previsibilidade ao receber dados, suporta a busca declarativa de dados e reduz a busca excessiva e insuficiente. Essencialmente, a busca excessiva ocorre quando um cliente baixa mais informações do que é realmente necessário no aplicativo, enquanto a busca insuficiente implica que um ponto de extremidade específico não forneceu informações suficientes, exigindo que o cliente faça solicitações adicionais para buscar o que precisa.

Tecnicamente, o GraphQL é um wrapper que pode ser definido, o que significa que você não precisa substituir totalmente um sistema REST. Essencialmente, isso significa que o GraphQL é compatível com sistemas com os quais as APIs centradas em REST são compatíveis. Além disso, o GraphQL permite o desenvolvimento contínuo e independente de front e back-end. Isso ocorre porque, uma vez que o esquema está bem definido, as equipes que trabalham no front-end e no back-end estão cientes da estrutura definida dos dados. Todos esses benefícios são vistos como vantajosos por muitos engenheiros full-stack. Por fim, o GraphQL tem uma incrível capacidade de introspecção completa e autodocumentação.

Casos de uso do GraphQL no desenvolvimento de API

Considerado extremamente poderoso, o GraphQL é usado por desenvolvedores Full-stack que buscam legibilidade estável com velocidade e indexação rápidas. Especificamente, o GraphQL é útil no desenvolvimento de API que requer alta taxa de transferência de dados. Na verdade, ele minimiza a quantidade de dados necessária para a transferência em uma rede. Isso é altamente benéfico para usuários móveis, dispositivos de baixa potência e redes desleixadas. Essa é uma das razões iniciais pelas quais o Facebook projetou o GraphQL. Ao contrário do que se pensa, o GraphQL não é aplicável apenas em bancos de dados enormes e complexos, ele pode criar bancos de dados relativamente simples com maior eficiência.

Além disso, pode ser aplicado em uma variedade de estruturas e plataformas front-end exclusivas, fornecendo um cenário heterogêneo mantido com uma API para atender a todos os requisitos do usuário. Além disso, facilita o desenvolvimento rápido de recursos, pois aumenta drasticamente a velocidade dos recursos para equipes de desenvolvedores full-stack. Ele faz isso reduzindo a comunicação necessária entre as equipes enquanto desenvolve novos recursos, pois os desenvolvedores de front-end podem fazer solicitações de API, por exemplo, para introduzir novos recursos ou alterar os existentes sem ter que esperar que os desenvolvedores de back-end entreguem. Este resumo rápido do GraphQL deve ser suficiente por enquanto, à medida que entramos em nossa introdução ao mecanismo Hasura GraphQL. Mas vamos tocar no PostgreSQL para um pouco mais de contexto.

O que é PostgreSQL?

Como um sistema gratuito de gerenciamento de banco de dados relacional orientado pela comunidade, o PostgreSQL não pertence a nenhuma empresa. Considerado o RDBMS mais poderoso e internamente consistente disponível, o Postgres foi escrito em C e suporta várias linguagens de programação, como C/C++, JavaScript, Java, Python, R, Go, Lisp, .Net etc. Cada vez mais preferido entre a maioria desenvolvedores full-stack, o PostgreSQL é mais rico em recursos do que seu irmão MySQL, ganhando popularidade por causa de seus recursos, escalabilidade e desempenho. O PostgreSQL é popular em projetos em que os requisitos giram em torno de procedimentos complexos, designs intrincados, integração sob medida e integridade de dados.

Vantagens do Postgres para desenvolvedores Full-Stack

Geralmente, recursos como pesquisa de texto completo, colunas JSON, replicação lógica, dão ao Postgres vantagem sobre o MySQL. Isso é ideal para as demandas de desempenho de bancos de dados comerciais típicos, ao mesmo tempo em que permite a consolidação de vários sistemas de banco de dados em um com menos despesas gerais e custos. Além disso, seus recursos mais recentes para armazenamento de valor-chave (tipos de coluna JSON / JSONB) o tornam uma alternativa adequada aos bancos de dados NoSQL. Além disso, ele suporta clustering ou uma arquitetura mestre-escravo, tornando-o adequado para ambientes semelhantes a nuvem. Além disso, sua popular extensão external-data-wrapper permite a consulta de fontes externas diretamente do PostgreSQL quando necessário. Especificamente, é mais adequado para sistemas que exigem execução de consultas complexas, armazenamento de dados e análise dinâmica de dados.

Na verdade, o PostgreSQL suporta melhor certos recursos que o MySQL não suporta. Por exemplo, verifique restrições, tipos de dados avançados (como arrays, mapas, JSON), suporte geoespacial mais avançado (PostGIS) e suporte a texto completo mais avançado. Além disso, ele suporta a criação de índice sem bloqueio, índices parciais, expressões de tabela comuns e funções de análise mais dinâmicas. Não obstante, o PostgreSQL oferece suporte SLL nativo para conexões para criptografia de comunicações cliente/servidor, bem como um aprimoramento embutido chamado SE-PostgreSQL que fornece controles de acesso adicionais baseados na política SELinux.

Com muitos recursos avançados para produtos de nível empresarial, o PostgreSQL é apropriado para grandes sistemas em que os dados exigem autenticação e as velocidades de leitura/gravação são essenciais para o sucesso do projeto. Além disso, ele também suporta vários aprimoradores de desempenho que normalmente estão disponíveis em soluções proprietárias. Tais incluem: simultaneidade sem bloqueios de leitura, servidor SQL e suporte a dados geoespaciais, para citar alguns.

Outra vantagem principal da arquitetura Postgres é sua extensibilidade única. Ele permite que os usuários adicionem recursos como tipos de dados, métodos de acesso a índices, linguagens de programação de servidor, wrappers de dados estrangeiros (FDW) e extensões carregáveis ​​sem alterar o código do sistema central. Ele aproveita uma arquitetura moderna de processador multi-core, portanto, permite que seu desempenho cresça quase linearmente à medida que o número de núcleos aumenta. Isso é importante Geralmente, recursos como pesquisa de texto completo, colunas JSON, replicação lógica, dão ao Postgres uma vantagem sobre o MySQL. Isso é ideal para as demandas de desempenho de bancos de dados comerciais típicos, ao mesmo tempo em que permite a consolidação de vários sistemas de banco de dados em um com menos despesas gerais e custos. Além disso, seus recursos mais recentes para armazenamento de valor-chave (tipos de coluna JSON / JSONB) o tornam uma alternativa adequada aos bancos de dados NoSQL. Além disso, ele suporta clustering ou uma arquitetura mestre-escravo, tornando-o adequado para ambientes semelhantes a nuvem. Além disso, sua popular extensão external-data-wrapper permite a consulta de fontes externas diretamente do PostgreSQL quando necessário. Especificamente, é mais adequado para sistemas que exigem execução de consultas complexas, armazenamento de dados e análise dinâmica de dados.

Contras do PostgreSQL

Geralmente, se você gosta dos padrões ANSI SQL, considere o PostgreSQL, mas se você preferir os padrões ODBC, opte pelo MySQL. Infelizmente, o Postgres ocasionalmente fica aquém do desempenho com ambientes de produção ao vivo, “sempre ativos”. Uma desvantagem adicional do Postgres é o fato de sua replicação ser implementada no nível do mecanismo de armazenamento. Isso o torna mais caro do que a replicação do MySQL, que é mais madura e implementada no “nível do mecanismo de consulta”.

Introdução ao mecanismo Hasura GraphQL

Como abordamos brevemente o desenvolvimento da API GraphQL e o PostgreSQL, devemos ter contexto suficiente para uma introdução ao mecanismo Hasura GraphQL. Basicamente, Hasura é simplesmente um mecanismo GraphQL para o PostgreSQL RDBMS, fornecendo uma maneira simplificada de inicializar e gerenciar o desenvolvimento da API GraphQL. Em retrospecto, Hasura é atualmente a única solução prontamente disponível que adiciona instantaneamente GraphQL-as-a-Service a aplicativos existentes baseados em PostgreSQL. Essencialmente, ignorando a tarefa demorada de escrever o código de back-end que processa o GraphQL.

Hasura simplificado

Vamos tomar um minuto para simplificar ainda mais o Hasura. Basicamente, as APIs são interfaces que permitem solicitar informações (uma consulta) e, assim, responder enviando dados JSON ou XML. Esse banco de dados normalmente é hospedado e obtido de um servidor. É aqui que Hasura entra para simplificar as coisas. Em retrospectiva, o mecanismo Hasura GraphQL é um servidor que lida com suas consultas GraphQL em um banco de dados Postgres. Isso reduz efetivamente o tempo que seu aplicativo leva para estar pronto para produção, permitindo que você crie, visualize e modifique tabelas do seu banco de dados com facilidade em apenas alguns cliques. Consequentemente, isso permite que desenvolvedores full-stack criem aplicativos GraphQL escaláveis ​​no PostgreSQL em menos tempo. Isso economiza semanas de codificação inicial dos desenvolvedores e pode impedir que bugs problemáticos de vazamento de dados cheguem à produção.

Qual problema a Hasura está resolvendo no desenvolvimento de API?

Geralmente, Hasura simplifica o gerenciamento do ciclo de vida da API durante o uso de produção em larga escala, especialmente para APIs complexas. Acima de tudo, o GraphQL Engine atrai desenvolvedores full-stack que estão sobrecarregados com projetos de desenvolvimento de API corporativa utilizando bancos de dados PostgreSQL existentes. Idealmente, como o GraphQL permite ciclos de desenvolvimento de API extremamente rápidos, o Hasura fornece uma maneira simplificada para as organizações migrarem incrementalmente para o GraphQL, sem afetar os aplicativos, bancos de dados ou usuários existentes. Além de sua leveza e alto desempenho, o mecanismo vem com uma interface de usuário de administração, permitindo que você explore suas APIs GraphQL e gerencie seu esquema e dados de banco de dados visualmente.

Vantagens do Hasura

Em primeiro lugar, Hasura possui um modelo sólido e estável para gerenciar mudanças ou “migrações” de banco de dados. Isso é vantajoso, pois o gerenciamento de esquema de banco de dados geralmente é complicado. Por exemplo, tarefas como; acompanhamento de alterações ao longo do tempo e associação de alterações de esquema com aprimoramentos de API (gerenciamento de esquema). Além disso, trabalhos de rotina, como manutenção de scripts que podem implantar um banco de dados novo ou reverter alterações, podem ser tediosos e causar erros ou interrupções difíceis de diagnosticar. Como uma nota positiva, os componentes de migração do banco de dados Hasura são SQL simples, portanto, portáteis fora do conjunto de ferramentas Hasura. Em suma, Hasura possui ótimos recursos de gerenciamento de esquema e você não precisa escrever código para lidar com conexões de soquete da web.

Em segundo lugar, o mecanismo Hasura GraphQL facilita a busca de dados necessários com uma única consulta. Ele faz isso permitindo que você adicione exibições como relacionamentos a tabelas ou outras exibições. Além disso, permite a gravação de resolvedores personalizados com costura de esquema e integração de funções sem servidor ou APIs de microsserviço que são acionadas em eventos de banco de dados. Isso pode ser útil e facilita a criação de aplicativos de 3 fatores. Na verdade, Hasura é um motor extremamente leve. Em retrospecto, ele consome apenas até 50 MB de RAM, mesmo atendendo a mais de 1.000 solicitações/por segundo. Um brilhante retorno sobre o investimento!

Especificamente, o Hasura facilita ainda mais a autenticação e a autenticação em nível de dados da API refinada. Ele permite a conexão com um provedor de autenticação preferencial via webhook, JWT, Auth0 ou implementações personalizadas. E assim, especificação de papéis para usuários, definindo quem pode acessar dados diferentes, por exemplo, admin, usuários anônimos, etc. Geralmente, seu sistema de controle de acesso granular é baseado na estrutura de tabelas do banco de dados semelhante ao esquema GraphQL. Além disso, as regras de permissão personalizadas são estritamente definidas com base nas operações e valores do banco de dados.

Por fim, o Hasura suporta de forma brilhante a paginação eficiente com um modelo de deslocamento/limite simples semelhante ao SQL. Por exemplo, ele usa o modelo de controle de acesso para restringir o número de linhas retornadas para uma determinada consulta. Seu modelo permite ajuste de limites por função. Por exemplo, os usuários que impõem uma taxa de solicitação muito mais alta estão limitados a limites de linha menores. Isso evita sobrecarregar o banco de dados e o mecanismo GraphQL. Além disso, o Hasura não restringe você apenas ao GraphQL. Você ainda pode executar REST ou outros microsserviços não GraphQL nas tabelas Postgres que o Hasura gerencia. Isso é possível com a costura automática do esquema do Hasura. Isso permite a mesclagem de um serviço GraphQL não Hasura e back-end para um único esquema unificado, combinando novas APIs gerenciadas pelo Hasura com APIs e dados herdados.

Casos de uso de Hasura

Adequado para ambientes de alto desempenho, o Hasura Engine oferece velocidade enquanto automatiza a implementação do GraphQL-Postgres em bancos de dados existentes. Consequentemente, isso fornece às empresas que já usam o Postgres uma maneira menos estressante e incremental de migrar para o GraphQL, vinculando tabelas existentes em um “gráfico”. Hasura cuida eficientemente da costura do esquema, permitindo que você aplique facilmente a lógica de negócios personalizada. Com esquemas remotos do GraphQL, o Hasura pode ser aproveitado como um gateway para lógica de negócios personalizada, permitindo que você grave em servidores GraphQL em seu idioma favorito e depois exponha os dados a um único endpoint. Além disso, Hasura tem uma ótima sintaxe para consultas e mutações com consultas ao vivo integradas chamadas assinaturas no GraphQL.

As poucas limitações de Hasura

Infelizmente, o modelo de sistema de controle de acesso da Hasura não funcionará totalmente para todos os aplicativos. Por exemplo, ele não oferece suporte total à autorização de acesso à API no nível de parâmetros de entrada individuais. Sem falar no fato de estar restrito ao banco de dados Postgres exigindo migração na maioria dos casos. Embora insignificantes, as mensagens de erro que a API GraphQL retorna para solicitações malformadas são bastante hostis no Hasura. Caso contrário, há pouco que Hasura não possa fazer como vimos nesta introdução ao Hasura GraphQL Engine.

Conclusão

Concluindo, à medida que o GraphQL cresce, ele simplificará ainda mais o desenvolvimento de APIs nas empresas para construir em escala web. Com a rápida adoção em larga escala do GraphQL em um conjunto diversificado de setores, a Hasura tem o potencial de automatizar ainda mais a criação e o gerenciamento de APIs com as tecnologias padrão do setor, GraphQL e Postgres. Hasura simplifica a criação de backends CRUD (Criar, ler, atualizar e excluir) GraphQL. Mais importante, Hasura é de longe a melhor e única opção se você está começando do zero com uma API centrada em GraphQL e Postgres, sem escrever código de back-end. Para quaisquer dúvidas ou consultas sobre as possibilidades corporativas do GraphQL e Hasura, sinta-se à vontade para entrar em contato conosco. Isso é tudo para a nossa introdução ao Hasura GraphQL Engine.