GraphQL devient rapidement un langage de recherche incontournable pour que les entreprises interagissent avec leurs données. Bien que la gestion des données soit l’une des principales préoccupations de nombreuses entreprises, de nombreuses personnes ne comprennent pas vraiment ce que fait GraphQL ni pourquoi il est si populaire.
Habituellement, le monde produit environ 2,5 quintillions d’octets d’informations par jour. Les organisations ont besoin d’une méthode pour recueillir ces informations et les utiliser efficacement. De nombreuses informations sont produites dans les applications (par exemple, une application de service client pour téléphone portable qui permet aux clients de vous informer s’ils sont satisfaits ou s’ils rencontrent des problèmes et ont besoin d’aide pour le dépannage). Les applications ont besoin d’un moyen de transmettre des informations au 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 ont besoin d’informations du backend. Recommandations, état d’une expédition, soldes de compte. Et c’est à cela que sert GraphQL : obtenir des données vers et depuis le backend. Il s’agit d’une API plus moderne qui connecte les applications aux backends.
De nombreux leaders technologiques ont peut-être entendu parler de GraphQL, ils en ont probablement beaucoup plus entendu parler SQL (langage de questions structurées). SQL est fondamentalement la norme 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 une méthode pour obtenir les avantages des deux lors de l’exécution de requêtes ?
GraphQL vs SQL : la vue d’ensemble
GraphQL a un format relativement basique et lisible pour l’accès aux données. Le format unique permet quelque chose appelé « imbrication ». L’imbrication consiste à poser une question dans une autre préoccupation pour obtenir une réponse plus précise. Par exemple, au lieu de simplement demander une liste de tous les chiens d’un refuge particulier, vous pouvez demander une liste de tous les animaux de compagnie et des détails intégrés sur les races de ces chiens (tirés d’un site complètement différent, voire tiers). la source d’information).
La capacité de GraphQL à imbriquer les requêtes permet à un développeur frontal de récupérer, en une seule demande, les détails pertinents d’une API. Étant donné que GraphQL est presque un langage de questions universel, gérant facilement diverses sources de données, vous pouvez également interroger de nombreuses API et autres sources de données en même temps. GraphQL est le langage de recherche idéal pour les backends hétérogènes, impliquant des backends avec différents types de sources de données en plus des simples bases de données.
SQL est immensément populaire comme langage de requête pour les bases de données. Malheureusement, cela ne fonctionne pas pour les questions imbriquées sur des données hétérogènes de la même manière que GraphQL. De plus, la syntaxe de SQL peut être compliquée. SQL n’a jamais été conçu pour être universel. SQL fonctionne très bien pour différentes bases de données, mais pas si bien pour les API.
GraphQL vs SQL en action
Déclarons que vous travaillez pour réapprovisionner le stock de votre entreprise et que vous devez comprendre le numéro de suivi et la date de livraison prévue pour deux commandes différentes livrant à partir de deux diverses sociétés. GraphQL aurait la capacité d’obtenir toutes ces informations 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 d’autres termes, vous pouvez voir que la date d’expédition de votre colis est liée au numéro de suivi que vous avez obtenu.
Pour SQL, vous devrez peut-être faire une demande à votre base de données pour obtenir des informations générales sur les deux commandes différentes. Vous devrez peut-être trier ces informations pour découvrir 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 pourrait ne pas être simple d’obtenir la syntaxe idéale. Personnellement, je gère des bases de données SQL depuis des années, et même j’ai généralement besoin de rechercher la syntaxe pour des requêtes complexes.
Pourquoi SQL est-il toujours aussi populaire ?
Un schéma d’API GraphQL permet juste un sous-ensemble d’opérations, selon les développeurs qui exécutent cette API. En d’autres termes, la polyvalence de vos demandes dépend de la polyvalence des développeurs d’API. Par exemple, une API vous permet uniquement 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. Discuter rendu complexe.
Ou si vous traitez des informations sensibles, vous devrez peut-être configurer vos requêtes et vos API pour des facteurs tels que la gestion des personnes pouvant accéder aux données ou la durée pendant laquelle les données sont mises en cache (brièvement enregistrées) sur le backend. De telles configurations sont d’une importance capitale pour l’entreprise moyenne, mais de nombreuses technologies sont désormais disponibles pour gérer et configurer les requêtes et les API GraphQL pour vous. Ces innovations font de GraphQL une alternative pratique pour interroger les API, mais sans de telles innovations, la configuration peut être difficile.
D’autre part, SQL est plus expressif dès le départ, ce qui suggère qu’il est plus simple de dire au système ce que vous désirez sans beaucoup de configuration supplémentaire. On peut rapidement 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 donnera ce dont vous avez besoin, quelle que soit la structure de la base de données.
La méthode que j’aime dire est la suivante : GraphQL permet des questions flexibles 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 l’affaire.
Existe-t-il une méthode pour combler le fossé ?
Et si vous pouviez utiliser les qualités expressives de SQL et la polyvalence de GraphQL en même temps ? Il existe des technologies disponibles qui prétendent le faire, mais elles ne sont pas susceptibles de devenir populaires car elles finissent par être inconfortables et complexes. La gêne provient de la tentative de forcer les constructions SQL dans GraphQL. Ce sont des langages de recherche différents avec des objectifs différents. Si les développeurs 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.
Tout n’est pas perdu. Nous pensons que GraphQL deviendra progressivement plus expressif. Il existe des propositions pour rendre GraphQL plus expressif. Ceux-ci pourraient éventuellement devenir des normes. Cependant, SQL et GraphQL ont essentiellement différentes visions du monde, respectivement : des backends cohérents contre des backends variés, des tables contre des données 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 de requête API, ne va pas détrôner SQL en tant que langage principal pour l’accès aux bases de données.
.
Toute l’actualité en temps réel, est sur L’Entrepreneur
