GraphQL est un gros problème : pourquoi n’est-il pas le standard de l’industrie pour l’interrogation des bases de données ?

GraphQL est en passe de devenir un langage de requête incontournable permettant aux entreprises d’interagir avec leurs données. Bien que la gestion des données soit l’une des principales préoccupations de nombreuses entreprises, beaucoup de gens ne comprennent pas vraiment ce que fait GraphQL ou pourquoi il est si populaire.

En moyenne, le monde génère environ 2,5 quintillions d’octets de données par jour. Les entreprises ont besoin d’un moyen de collecter ces données et de les utiliser efficacement. De nombreuses données sont générées dans les applications (par exemple, une application de service client pour smartphone 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 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 données 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 données aux backends, mais les applications ont besoin de données du backend. Par exemple, les recommandations, le statut d’une livraison, les soldes des comptes. 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.

Bien que de nombreux leaders technologiques aient entendu parler de GraphQL, ils en ont probablement entendu beaucoup plus sur SQL (Structured Query Language). SQL est essentiellement 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 un moyen d’obtenir les avantages des deux lors de l’exécution de requêtes ?

GraphQL contre GraphQL SQL : la vue d’ensemble

GraphQL a un format relativement simple et lisible pour l’accès aux données. Le format unique permet quelque chose appelé “imbrication”. L’imbrication revient à poser une question dans une autre question 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 chiens et des détails imbriqués sur les races de ces chiens (tirés d’un tout autre, voire d’un troisième source de données du parti).

La capacité de GraphQL à imbriquer les requêtes permet à un développeur frontend de récupérer, en une seule requête, les informations pertinentes d’une API. Étant donné que GraphQL est presque un langage de requête universel, gérant facilement différentes sources de données, vous pouvez également interroger plusieurs API et d’autres sources de données en même temps. GraphQL est donc le bon langage de requête pour les backends hétérogènes, c’est-à-dire les backends avec différents types de sources de données en plus des bases de données.

SQL est extrêmement populaire en tant que langage de requête pour les bases de données. Malheureusement, cela ne fonctionne pas pour les requêtes 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. Enfin, 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 contre GraphQL SQL en action

Supposons que vous travaillez pour réapprovisionner l’inventaire de votre entreprise et que vous devez connaître le numéro de suivi et la date de livraison prévue pour deux commandes différentes expédiées par deux entreprises différentes. GraphQL serait en mesure d’obtenir toutes ces informations en une seule requête.

GraphQL vous montre également ces informations dans une structure hiérarchique qui permet de voir facilement la relation entre les éléments de données que vous avez demandés. En d’autres termes, 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 demande à votre base de données pour obtenir des informations générales sur les deux commandes différentes. Ensuite, vous devrez peut-être trier 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 toutes ces informations nécessiterait beaucoup de code, et il pourrait ne pas être facile d’obtenir la bonne syntaxe. Personnellement, je travaille avec des bases de données SQL depuis des décennies, et même je dois souvent rechercher la syntaxe pour des requêtes complexes.

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 développeurs qui implémentent cette API. En d’autres termes, la flexibilité de vos requêtes dépend de la flexibilité des développeurs d’API. Par exemple, une API vous permet uniquement de rechercher des clients par e-mail. Pour rechercher des clients par ville, l’application devrait rassembler tous les clients, puis les filtrer un par un. Parlez de compliqué.

Ou si vous traitez des données sensibles, vous devrez peut-être configurer vos requêtes et vos API pour des facteurs tels que le contrôle des personnes pouvant accéder aux données ou la durée pendant laquelle les données sont mises en cache (sauvegardées temporairement) sur le backend. De telles configurations sont un défi de taille 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 technologies font de GraphQL une option viable pour interroger les API, mais sans ces technologies, la configuration peut être difficile.

En revanche, SQL est plus expressif dès le départ, ce qui signifie qu’il est plus facile de dire au système ce que vous voulez sans beaucoup de configuration supplémentaire. On peut facilement demander à n’importe quelle base de données “pour le client 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 façon dont j’aime le dire est la suivante : GraphQL permet des requêtes flexibles dans le cadre défini par le développeur qui a construit 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 bien le travail.

Existe-t-il un moyen de combler le fossé?

Et si vous pouviez tirer parti des attributs expressifs de SQL et de 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 deviennent populaires car elles finissent par être maladroites et complexes. La gêne provient de la tentative de forcer les constructions SQL dans GraphQL. Mais ce sont des langages de requête différents avec des objectifs différents. Si les développeurs doivent apprendre à faire des constructions SQL dans GraphQL, ils peuvent tout aussi bien utiliser SQL et se connecter directement à la base de données.

Cependant, tout n’est pas perdu. Nous pensons que GraphQL deviendra plus expressif avec le temps. Il existe des propositions pour rendre GraphQL plus expressif. Ceux-ci pourraient éventuellement devenir des normes. Mais fondamentalement, SQL et GraphQL ont des visions du monde différentes, respectivement : backends uniformes vs. Backends divers, tables vs. données hiérarchiques et interrogation universelle vs. requête limitée. En conséquence, ils servent des objectifs différents.

GraphQL, malgré sa popularité en tant que langage de requête API, ne va pas renverser SQL en tant que langage principal pour l’accès aux bases de données.

Anant Jhingran est PDG et cofondateur de StepZen.