GraphQL devient rapidement un langage de requête incontournable permettant aux entreprises de communiquer avec leurs données. Bien que la gestion des données soit l’un des principaux problèmes de nombreuses entreprises, de nombreuses personnes ne comprennent pas réellement ce que fait GraphQL ni pourquoi il est si populaire.
En moyenne, le monde crée environ 2,5 quintillions d’octets de données chaque jour. Les entreprises ont besoin d’une méthode pour collecter ces informations et les utiliser avec succès. De nombreuses informations sont générées dans les applications (par exemple, une application de service client pour téléphone portable qui permet aux clients de vous dire s’ils sont satisfaits ou s’ils rencontrent des problèmes et ont besoin d’aide pour le dépannage). Les applications nécessitent un moyen d’obtenir des informations sur le backend ; c’est-à-dire les outils de gestion et de stockage des données. Ensuite, les informations peuvent être analysées pour découvrir les problèmes et développer des solutions. Et bien sûr, il est bidirectionnel. Non seulement les applications envoient des informations aux backends, mais les applications nécessitent des informations du backend. Recommandations, statut d’une livraison, soldes de compte. Et c’est à cela que sert GraphQL : Obtenir des informations vers et depuis le backend. Il s’agit d’une API plus moderne qui connecte les applications aux backends.
Bien que de nombreux leaders technologiques aient peut-être entendu parler de GraphQL, ils en ont probablement entendu beaucoup plus à propos de SQL (Structured Query Language). SQL est essentiellement l’exigence de l’industrie pour l’interrogation des bases de données, bien que GraphQL gagne en popularité.
Comment GraphQL se compare-t-il à SQL, et existe-t-il un moyen d’obtenir les avantages des deux lors de l’exécution de requêtes ?
GraphQL vs SQL : la vue d’ensemble
GraphQL a un format raisonnablement simple et lisible pour l’accès aux données. Le format distinct permet quelque chose appelé « imbrication ». L’imbrication revient à poser une question dans une autre question pour obtenir une réponse plus précise. Plutôt que de simplement demander une liste de tous les animaux de compagnie à un emplacement de refuge particulier, vous pouvez demander une liste de tous les chiens et des détails imbriqués sur les types de ces chiens de compagnie (tirés d’une base de données complètement différente, voire tierce. la source).
La capacité de GraphQL à imbriquer des requêtes permet à un concepteur frontal de récupérer, en une seule demande, les informations pertinentes à partir d’une API. Étant donné que GraphQL est presque un langage d’interrogation universel, gérant facilement diverses sources d’informations, vous pouvez également interroger plusieurs API et autres sources de données en même temps. GraphQL est le meilleur langage de questions pour les backends hétérogènes, impliquant des backends avec différents types de sources d’informations en plus des bases de données.
SQL est extrêmement populaire en tant que langage d’interrogation pour les bases de données. Malheureusement, cela ne fonctionne pas pour les requêtes imbriquées dans des données hétérogènes exactement de la même manière que GraphQL. De plus, la syntaxe de SQL peut être compliquée. Enfin, SQL n’a jamais été conçu pour être universel. SQL fonctionne de manière fantastique pour différentes bases de données, mais pas si fantastique pour les API.
GraphQL vs SQL en action
Déclarons que vous travaillez pour réapprovisionner l’inventaire de votre entreprise et que vous avez besoin de connaître le numéro de suivi et la date d’expédition prévue pour 2 commandes différentes livrées à partir de deux diverses sociétés. GraphQL aurait la capacité d’obtenir tous ces détails en une seule requête.
GraphQL vous révèle également ces informations dans une structure hiérarchique qui permet de voir facilement la relation entre les éléments d’information que vous avez demandés. En termes simples, vous pouvez voir que la date de livraison de votre colis est liée au numéro de suivi que vous avez reçu.
Pour SQL, vous devrez peut-être faire une requête à votre base de données pour obtenir des détails de base sur les 2 différentes commandes. Vous devrez peut-être organiser ces informations pour trouver les noms des compagnies maritimes, suivi d’une autre demande à chaque compagnie maritime pour les numéros de suivi. Enfin, en fonction du numéro de suivi, vous pouvez faire une autre demande pour obtenir les dates de livraison prévues. Obtenir tous ces détails nécessiterait beaucoup de code, et il ne serait peut-être pas facile d’obtenir une syntaxe parfaite. Personnellement, je travaille avec des bases de données SQL depuis des décennies, et même j’ai souvent besoin de rechercher la syntaxe pour des requêtes compliquées.
Pourquoi SQL est-il toujours aussi populaire ?
Un schéma d’API GraphQL n’autorise qu’un sous-ensemble d’opérations, en fonction des concepteurs qui implémentent cette API. Pour le dire simplement, la polyvalence de vos questions dépend de la polyvalence des développeurs d’API. Par exemple, une API vous permet simplement de rechercher des consommateurs par e-mail. Pour parcourir les clients par ville, l’application nécessiterait de rassembler tous les clients, puis de les filtrer un par un. Parlez de complexe rendu.
Ou si vous gérez des informations délicates, vous devrez peut-être configurer vos requêtes et vos API pour des éléments tels que la gestion des personnes pouvant accéder aux données ou la durée pendant laquelle les informations sont mises en cache (sauvegardées temporairement) sur le arrière-plan. De telles configurations sont un défi de taille pour l’entreprise typique, mais de nombreuses technologies sont désormais proposées pour gérer et configurer les questions et les API GraphQL pour vous. Ces technologies font de GraphQL une option pratique pour interroger les API, mais sans ces technologies, la configuration peut être difficile.
D’autre part, SQL est plus significatif dès le départ, ce qui implique qu’il est plus facile de dire au système ce que vous désirez sans beaucoup de configuration supplémentaire. On peut facilement demander à n’importe quelle base de données « pour le consommateur John Doe, donnez-moi des commandes dont le montant dépasse 100 $ », en utilisant une seule ligne de code. SQL vous offrira ce dont vous avez besoin, malgré la structure de la base de données.
La façon dont j’aime le dire est la suivante : GraphQL permet des enquêtes polyvalentes dans la structure définie par le concepteur qui a développé l’API. SQL permet une interrogation universelle sur n’importe quel modèle de base de données. Donc, si vous interrogez principalement des bases de données, SQL fera parfaitement le travail.
Existe-t-il une méthode pour combler le fossé ?
Et si vous pouviez utiliser les qualités expressives de SQL et la flexibilité de GraphQL en même temps ? Il existe des technologies disponibles qui prétendent le faire, mais il est peu probable qu’elles finissent par être populaires en raison du fait qu’elles finissent par être maladroites et complexes. La gêne provient de la tentative d’exiger des constructions SQL dans GraphQL. Cependant, ce sont des langages de requête différents avec diverses fonctions. Si les concepteurs doivent découvrir comment faire des constructions SQL dans GraphQL, ils peuvent aussi bien utiliser SQL et se connecter directement à la base de données.
Pourtant, tout n’est pas perdu. Nous pensons que GraphQL deviendra plus significatif avec le temps. Il existe des propositions pour rendre GraphQL plus expressif. Ceux-ci pourraient éventuellement devenir des exigences. Essentiellement, SQL et GraphQL ont des visions du monde différentes, respectivement : des backends cohérents contre des backends variés, des tables contre des informations hiérarchiques et des requêtes universelles contre des requêtes limitées. Par la suite, ils remplissent différentes fonctions.
GraphQL, malgré sa popularité en tant que langage d’interrogation d’API, ne va pas renverser SQL en tant que langage principal auquel accéder aux bases de données.
.
Toute l’actualité en temps réel, est sur L’Entrepreneur
