Introduction au moteur Hasura GraphQL pour les API dynamiques avec PostgreSQL

Généralement, au cours des dernières années, les API REST ont été critiquées comme étant inflexibles tout en faisant face à des exigences technologiques en évolution rapide. Rétrospectivement, beaucoup pensent que GraphQL a été créé pour faire face à ce besoin de flexibilité et d'efficacité supplémentaires dans le développement d'API. Ainsi, atténuant les lacunes des API REST. À la suite de la transition de Facebook des applications HTML5 vers des configurations plus robustes et natives, GraphQL a gagné en popularité et en adoption au cours des cinq dernières années pour une bonne raison. Dans ce blog, nous allons nous plonger dans le phénomène GraphQL, PostgreSQL et plus tard avoir une introduction approfondie au moteur Hasura GraphQL. Dans un extrait, la relation et l'écosystème du moteur Hasura GraphQL-PostgreSQL.

GraphQL : une rébellion Facebook

Alors que beaucoup pensent que GraphQL a été créé comme une rébellion contre les API REST, cela pourrait être plus éloigné de la vérité. Ironiquement, il a été créé pour simplement répondre à un besoin interne chez Facebook. Conçu à l'origine et open source par l'équipe Facebook, GraphQL est souvent confondu avec une technologie de base de données. Essentiellement, malgré l'idée fausse, GraphQL est techniquement un langage de requête pour les API et non pour les bases de données. Par conséquent, cela réduit la complexité de la création d'API, en faisant abstraction de toutes les demandes vers un seul point de terminaison. Contrairement aux API REST traditionnelles, GraphQL est déclaratif, ce qui signifie que tout ce qui est demandé est renvoyé. Cependant, pour obtenir un peu plus de contexte, nous devrons prendre du recul et revoir les API REST.

L'architecture REST

Généralement, les API sont des règles, des routines ou des protocoles qui spécifient comment les composants logiciels doivent interagir. Le transfert d'état représentatif (REST) ​​est essentiellement une architecture de conception d'API normalement exploitée dans la mise en œuvre de services Web où tout est considéré comme une «ressource». Malheureusement, la méthodologie RESTful était systématiquement limitée au traitement de ressources uniques. Par conséquent, si des données étaient nécessaires et provenant de deux ressources ou plus, par exemple, des publications et des utilisateurs, des allers-retours multiples vers le serveur seraient nécessaires pour collecter tout ce dont vous avez besoin. De plus, REST a rencontré des problèmes avec la récupération "plus" et "moins". Tout cela n'était pas idéal, en particulier avec l'émergence d'applications plus axées sur les données gérant de grands ensembles de données combinant des ressources connexes. Ce qui pourrait expliquer la situation difficile à laquelle Facebook était confronté.

D'où la nécessité d'une architecture API qui adopterait une approche plus flexible et progressive.

La création d'une alternative

Alternativement, GraphQL ne pense pas aux données en termes d'URL de ressources, de clés secondaires ou de tables, mais en termes de graphique d'objets et de modèles utilisant NSObjects ou JSON. Plus précisément, GraphQL n'a pas besoin de points de terminaison dédiés par cas d'utilisation, car différentes capacités et cas d'utilisation peuvent être représentés dans un seul « graphique ». En utilisant le langage de requête GraphQL, vous pouvez décrire exactement à quoi la réponse devrait ressembler, donc aucun aller-retour supplémentaire vers le serveur n'est nécessaire. En tant que langage de requête de la couche application, il est conçu pour interpréter une chaîne à partir d'un serveur/client et renvoyer ces données dans un format stable, compréhensible et prévisible. C'est simplement un outil pour mieux consolider les données.

Simplicité, Stabilité et Efficacité.

La vérité est que tous les projets ne nécessitent pas GraphQL malgré son schéma bien défini, nous savons donc avec certitude que nous n'allons pas trop chercher. Cependant, si nous avons un produit d'entreprise qui s'appuie sur des données provenant de plusieurs sources, par exemple MySQL, Postgres et d'autres API, alors GraphQL est la meilleure option. GraphQL est fier de sa simplicité, en particulier en ce qui concerne la récupération des données, car les données sont collectées sous un point de terminaison ou un appel commun. Essentiellement, puisque les clients obtiennent exactement ce dont ils ont besoin, cela réduit efficacement la taille de chaque demande faite par le client, ce qui se traduit par des applications hautes performances. Étant donné que GraphQL unifie les données qui nécessiteraient autrement plusieurs points de terminaison, il facilite les récupérations répétées complexes, améliorant ainsi l'efficacité des requêtes. Par conséquent, sa simplicité s'accompagne d'une stabilité, d'une planification, d'une construction, d'une exécution et d'un fonctionnement continus dans le temps.

Avantages de GraphQL

En un mot, GraphQL permet l'extraction de données avec des requêtes facilement compréhensibles, permet le développement rapide d'applications légères et rapides car les données sont accessibles plus directement que via un serveur. De plus, il permet la récupération de plusieurs ressources avec une seule requête sans utiliser plusieurs URL ou chaînage de ressources, tout en utilisant un point de terminaison pour toutes les données. N'oubliez pas que les données sont définies sur le serveur avec un schéma basé sur des graphes, elles sont donc livrées sous forme de package plutôt que via plusieurs appels. Cela permet un coup de pouce opérationnel dans l'agrégation des réponses de l'API pendant le développement de l'API.

Ceci, à son tour, réduit la charge des équipes de développement frontales, facilite la gestion des versions des API, simplifie la maintenance et permet d'économiser sur les demandes de transfert de données. En outre, il permet une plus grande prévisibilité lors de la réception des données, prend en charge la récupération déclarative des données et atténue la sur-extraction et la sous-extraction. Essentiellement, la sur-récupération se produit lorsqu'un client télécharge plus d'informations que ce qui est réellement requis dans l'application, tandis que la sous-récupération implique qu'un point de terminaison spécifique n'a pas fourni suffisamment d'informations, ce qui oblige le client à faire des demandes supplémentaires pour récupérer ce dont il a besoin.

Techniquement, GraphQL est un wrapper qui peut être défini, ce qui signifie que vous n'avez pas à remplacer complètement un système REST. Cela signifie essentiellement que GraphQL est compatible avec les systèmes avec lesquels les API centrées sur REST sont compatibles. De plus, GraphQL permet un développement transparent et indépendant du front et du back-end. En effet, une fois le schéma bien défini, les équipes travaillant sur le front-end et le back-end sont toutes deux conscientes de la structure définie des données. Tous ces avantages sont considérés comme avantageux par de nombreux ingénieurs full-stack. Enfin, GraphQL a une incroyable capacité d'introspection et d'auto-documentation approfondies.

Cas d'utilisation de GraphQL dans le développement d'API

Considéré comme extrêmement puissant, GraphQL est utilisé par les développeurs Full-stack à la recherche d'une lisibilité stable avec une vitesse et une indexation rapides. Plus précisément, GraphQL est utile dans le développement d'API qui nécessite un débit de données élevé. En fait, il minimise la quantité de données nécessaires pour le transfert sur un réseau. Ceci est très bénéfique pour les utilisateurs mobiles, les appareils à faible puissance et les réseaux bâclés. C'est l'une des premières raisons pour lesquelles Facebook a conçu GraphQL. Contrairement à la croyance, GraphQL n'est pas seulement applicable dans d'énormes bases de données complexes, il peut créer des bases de données relativement simples avec une plus grande efficacité.

De plus, il peut être appliqué sur une variété de frameworks et de plateformes frontaux uniques, fournissant un paysage hétérogène maintenu avec une API pour répondre à tous les besoins des utilisateurs. De plus, il facilite le développement rapide des fonctionnalités car il augmente considérablement la vélocité des fonctionnalités pour les équipes de développeurs full-stack. Pour ce faire, il réduit la communication requise entre les équipes tout en développant de nouvelles fonctionnalités, car les développeurs front-end peuvent faire des demandes d'API, par exemple, pour introduire de nouvelles fonctionnalités ou modifier celles existantes sans avoir à attendre que les développeurs back-end les livrent. Ce résumé rapide de GraphQL devrait être suffisant pour l'instant alors que nous entrons dans notre introduction au moteur Hasura GraphQL. Mais abordons PostgreSQL pour un peu plus de contexte.

Qu'est-ce que PostgreSQL ?

En tant que système libre de gestion de bases de données relationnelles piloté par la communauté, PostgreSQL n'appartient à aucune entreprise en particulier. Considéré comme le SGBDR le plus puissant et le plus cohérent disponible, Postgres a été écrit en C et prend en charge un certain nombre de langages de programmation, tels que C/C++, JavaScript, Java, Python, R, Go, Lisp, .Net, etc. Développeurs full-stack, PostgreSQL est plus riche en fonctionnalités que sa sœur MySQL, gagnant en popularité en raison de ses fonctionnalités, de son évolutivité et de ses performances. PostgreSQL est populaire dans les projets où les exigences tournent autour de procédures complexes, de conceptions complexes, d'intégration sur mesure et d'intégrité des données.

Avantages de Postgres pour les développeurs Full-Stack

Généralement, des fonctionnalités telles que la recherche en texte intégral, les colonnes JSON, la réplication logique, donnent à Postgres le dessus sur MySQL. Ceci est optimal pour les exigences de performances des bases de données commerciales typiques tout en permettant la consolidation de plusieurs systèmes de bases de données en un seul pour moins de frais généraux et de coûts. De plus, ses fonctionnalités plus récentes pour Key-Value-Storage (types de colonnes JSON / JSONB) en font une alternative appropriée aux bases de données NoSQL. De plus, il prend en charge le clustering ou une architecture maître-esclave, ce qui le rend bien adapté aux environnements de type cloud. De plus, sa populaire extension de wrapper de données étrangères permet d'interroger des sources externes directement depuis PostgreSQL lorsque cela est nécessaire. Plus précisément, il convient mieux aux systèmes nécessitant l'exécution de requêtes complexes, l'entreposage de données et l'analyse dynamique des données.

En fait, PostgreSQL prend mieux en charge certaines fonctionnalités que MySQL ne prend pas en charge. Par exemple, vérifiez les contraintes, les types de données riches (tels que les tableaux, les cartes, JSON), la prise en charge géospatiale plus riche (PostGIS) et la prise en charge de texte intégral plus riche. De plus, il prend en charge la création d'index non bloquants, les index partiels, les expressions de table communes et des fonctions d'analyse plus dynamiques. Néanmoins, PostgreSQL offre un support SLL natif pour les connexions pour le chiffrement des communications client/serveur, ainsi qu'une amélioration intégrée nommée SE-PostgreSQL qui fournit des contrôles d'accès supplémentaires basés sur la politique SELinux.

Avec de nombreuses fonctionnalités riches pour les produits d'entreprise, PostgreSQL convient aux grands systèmes où les données nécessitent une authentification et où les vitesses de lecture/écriture sont essentielles à la réussite du projet. En outre, il prend également en charge plusieurs amplificateurs de performances qui sont normalement disponibles dans les solutions propriétaires. Ceux-ci incluent: la concurrence sans verrous de lecture, le serveur SQL et la prise en charge des données géospatiales pour n'en citer que quelques-uns.

Un autre avantage principal de l'architecture Postgres est son extensibilité unique. Il permet aux utilisateurs d'ajouter des fonctionnalités telles que des types de données, des méthodes d'accès à l'index, des langages de programmation de serveur, des wrappers de données étrangères (FDW) et des extensions chargeables sans modifier le code du système principal. Il s'appuie sur une architecture de processeur multicœur moderne, ce qui permet à ses performances de croître de manière presque linéaire à mesure que le nombre de cœurs augmente. Ceci est important. Généralement, des fonctionnalités telles que la recherche en texte intégral, les colonnes JSON, la réplication logique, donnent à Postgres le dessus sur MySQL. Ceci est optimal pour les exigences de performances des bases de données commerciales typiques tout en permettant la consolidation de plusieurs systèmes de bases de données en un seul pour moins de frais généraux et de coûts. De plus, ses fonctionnalités plus récentes pour Key-Value-Storage (types de colonnes JSON / JSONB) en font une alternative appropriée aux bases de données NoSQL. De plus, il prend en charge le clustering ou une architecture maître-esclave, ce qui le rend bien adapté aux environnements de type cloud. De plus, sa populaire extension de wrapper de données étrangères permet d'interroger des sources externes directement depuis PostgreSQL lorsque cela est nécessaire. Plus précisément, il convient mieux aux systèmes nécessitant l'exécution de requêtes complexes, l'entreposage de données et l'analyse dynamique des données.

Inconvénients de PostgreSQL

En règle générale, si vous aimez les normes SQL ANSI, envisagez PostgreSQL, mais si vous préférez les normes ODBC, optez pour MySQL. Malheureusement, Postgres manque parfois de performances avec des environnements de production en direct, « toujours prêts ». Un inconvénient supplémentaire avec Postgres est le fait que sa réplication est implémentée au niveau du moteur de stockage. Cela le rend plus cher que la réplication de MySQL, qui est plus mature et implémentée au « niveau du moteur de requête ».

Introduction au moteur Hasura GraphQL

Puisque nous avons brièvement couvert le développement de l'API GraphQL et PostgreSQL, nous devrions avoir suffisamment de contexte pour une introduction au moteur Hasura GraphQL. Fondamentalement, Hasura est simplement un moteur GraphQL pour le SGBDR PostgreSQL, offrant un moyen simplifié d'amorcer et de gérer le développement de l'API GraphQL. Rétrospectivement, Hasura est actuellement la seule solution facilement disponible qui ajoute instantanément GraphQL-as-a-Service aux applications existantes basées sur PostgreSQL. Essentiellement, en contournant la tâche fastidieuse d'écrire du code backend qui traite GraphQL.

Hasura simplifié

Prenons une minute pour simplifier davantage Hasura. Fondamentalement, les API sont des interfaces qui permettent de demander des informations (une requête), et donc de répondre en envoyant des données JSON ou XML. Cette base de données est normalement hébergée et extraite d'un serveur. C'est là qu'Hasura intervient pour simplifier les choses. Avec le recul, le moteur Hasura GraphQL est un serveur qui gère vos requêtes GraphQL sur une base de données Postgres. Cela réduit efficacement le temps nécessaire à la mise en production de votre application, ce qui vous permet de créer, d'afficher et de modifier facilement les tables de votre base de données en quelques clics. Par conséquent, cela permet aux développeurs full-stack de créer des applications GraphQL évolutives sur PostgreSQL dans un délai plus court. Cela permet aux développeurs d'économiser des semaines de codage initial et peut empêcher les bogues problématiques de fuite de données d'atteindre la production.

Quel problème Hasura résout-il dans le développement d'API ?

Généralement, Hasura simplifie la gestion du cycle de vie des API lors d'une utilisation en production à grande échelle, en particulier pour les API complexes. Surtout, le moteur GraphQL attire les développeurs full-stack qui sont en attente de projets de développement d'API d'entreprise utilisant des bases de données PostgreSQL existantes. Idéalement, étant donné que GraphQL permet des cycles de développement d'API ultra-rapides, Hasura offre aux organisations un moyen simplifié de passer progressivement à GraphQL, sans affecter les applications, bases de données ou utilisateurs existants. Outre sa légèreté et ses hautes performances, le moteur est livré avec une interface utilisateur d'administration, vous permettant d'explorer vos API GraphQL et de gérer visuellement le schéma et les données de votre base de données.

Avantages de Hasura

Premièrement, Hasura dispose d'un modèle solide et stable pour gérer les changements de base de données ou les "migrations". Ceci est avantageux car la gestion des schémas de base de données est souvent délicate. Par exemple, des tâches telles que ; suivi des modifications au fil du temps et association des modifications de schéma aux améliorations de l'API (gestion de schéma). De plus, les tâches de routine telles que la maintenance de scripts pouvant déployer une nouvelle base de données ou annuler des modifications peuvent s'avérer fastidieuses et entraîner des bogues difficiles à diagnostiquer ou une panne. Comme remarque positive, les composants de migration de base de données Hasura sont en langage SQL simple, donc portables en dehors de l'ensemble d'outils Hasura. Dans l'ensemble, Hasura possède d'excellentes fonctionnalités de gestion de schéma et vous n'avez pas besoin d'écrire de code pour gérer les connexions de socket Web.

Deuxièmement, le moteur Hasura GraphQL facilite la récupération des données requises avec une seule requête. Il le fait en vous permettant d'ajouter des vues en tant que relations avec des tables ou d'autres vues. De plus, il permet l'écriture de résolveurs personnalisés avec l'assemblage de schémas et l'intégration de fonctions sans serveur ou d'API de microservice qui se déclenchent sur des événements de base de données. Cela peut être utile et facilite la création d'applications 3factor. En fait, Hasura est un moteur extrêmement léger. Rétrospectivement, il ne consomme que jusqu'à 50 Mo de RAM, même en traitant plus de 1000 requêtes/par seconde. Un brillant retour sur investissement !

Plus précisément, Hasura facilite également l'autorisation et l'authentification fines au niveau des données de l'API. Il permet la connexion à un fournisseur d'authentification préféré via webhook, JWT, Auth0 ou des implémentations personnalisées. Et donc, spécification des rôles pour les utilisateurs, définissant qui peut accéder à différentes données, par exemple, administrateur, utilisateurs anonymes, etc. Généralement, son système de contrôle d'accès granulaire est basé sur la structure de table de base de données similaire au schéma GraphQL. De plus, les règles d'autorisation personnalisées sont strictement définies en fonction des opérations et des valeurs de la base de données.

Enfin, Hasura prend brillamment en charge la pagination efficace avec un simple modèle de décalage/limite de type SQL. Par exemple, il utilise le modèle de contrôle d'accès pour limiter le nombre de lignes renvoyées pour une requête donnée. Son modèle permet d'ajuster les limites par rôle. Par exemple, les utilisateurs qui imposent un taux de demande beaucoup plus élevé sont limités à des limites de lignes plus petites. Cela évite de stresser la base de données et le moteur GraphQL. De plus, notamment, Hasura ne vous limite pas uniquement à GraphQL. Vous pouvez toujours exécuter REST ou d'autres micro-services non-GraphQL sur les tables Postgres gérées par Hasura. Ceci est possible avec l'assemblage automatique de schémas de Hasura. Cela permet la fusion d'un service et d'un back-end non-Hasura GraphQL pour un seul schéma unifié, combinant de nouvelles API gérées par Hasura avec des API et des données héritées.

Cas d'utilisation Hasura

Adapté aux environnements hautes performances, le moteur Hasura offre de la vitesse tout en automatisant la mise en œuvre de GraphQL-Postgres sur les bases de données existantes. Par conséquent, cela offre aux entreprises qui utilisent déjà Postgres un moyen moins stressant et incrémentiel de passer à GraphQL en reliant les tables existantes dans un « graphe ». Hasura s'occupe efficacement de l'assemblage du schéma, ce qui vous permet d'appliquer facilement une logique métier personnalisée. Avec les schémas Remote GraphQL, Hasura peut être utilisé comme une passerelle pour une logique métier personnalisée vous permettant d'écrire sur les serveurs GraphQL dans votre langue préférée, puis d'exposer ultérieurement les données à un point de terminaison unique. De plus, Hasura a une excellente syntaxe pour les requêtes et les mutations avec des requêtes en direct intégrées appelées abonnements dans GraphQL.

Les quelques limites Hasura

Malheureusement, le modèle de système de contrôle d'accès d'Hasura ne fonctionnera pas entièrement pour toutes les applications. Par exemple, il ne prend pas entièrement en charge l'autorisation d'accès à l'API au niveau des paramètres d'entrée individuels. Sans parler du fait qu'il est limité à la base de données Postgres nécessitant une migration dans la plupart des cas. Bien que négligeables, les messages d'erreur renvoyés par l'API GraphQL pour les requêtes malformées sont assez hostiles à Hasura. Sinon, Hasura ne peut pas faire grand-chose comme nous l'avons vu dans cette introduction à Hasura GraphQL Engine.

Conclusion

En conclusion, à mesure que GraphQL se développe, il simplifiera encore davantage le développement d'API au sein des entreprises pour créer à l'échelle du Web. Avec l'adoption rapide à grande échelle de GraphQL dans un ensemble diversifié d'industries, Hasura a le potentiel d'automatiser davantage la création et la gestion des API avec les technologies standard de l'industrie de choix, GraphQL et Postgres. Hasura simplifie la création des backends CRUD (créer, lire, mettre à jour et supprimer) GraphQL. Plus important encore, Hasura est de loin la meilleure et la seule option si vous partez de zéro avec une API centrée sur GraphQL et Postgres, sans écrire de code backend. Pour toute question ou consultation sur les possibilités d'entreprise de GraphQL et Hasura, n'hésitez pas à nous contacter. C'est tout pour notre introduction au moteur Hasura GraphQL.