Le rôle et l'impact de GraphQL

GraphQL est devenu une approche moderne et efficace du développement d'API, surpassant les limites des API REST traditionnelles. Alors que REST est largement utilisé depuis les débuts du Web, GraphQL offre une nouvelle perspective et un meilleur contrôle pour les développeurs. Avec GraphQL, les développeurs peuvent définir un schéma fortement typé qui permet aux clients de demander précisément les données dont ils ont besoin. En éliminant la sur-extraction et la sous-extraction des données, GraphQL optimise les performances et facilite la création d'applications Web modernes et interactives qui ont des exigences complexes en matière d'interrogation et de modélisation des données.

Cependant, nous reconnaissons que GraphQL n’est pas sans défis. Cet article fournit un aperçu des problèmes de sécurité et de la courbe d’apprentissage associés à l’adoption de GraphQL. Nous explorons des études de cas réelles décrivant les avantages obtenus par des entreprises renommées qui ont mis en œuvre avec succès GraphQL.

De plus, nous présentons notre propre enquête sur GraphQL, partageant nos expériences et nos découvertes. Nous présentons une brève introduction à GraphQL, le comparons à REST et examinons les défis auxquels il répond. Les considérations de sécurité sont également abordées pour aider les organisations à prendre des décisions éclairées. Nos recherches révèlent le potentiel transformateur de GraphQL. Nous montrons comment nous avons simplifié l'architecture d'une suite logicielle de gestion de tests, ce qui a entraîné une croissance de plus de 300 % de la quantité de données exposées cachées dans les objets JSON via GraphQL.

En conclusion, nous recommandons vivement aux entreprises confrontées à la mise à l’échelle, à l’optimisation ou à l’exploitation d’une infrastructure d’API REST de considérer GraphQL comme une solution viable. Nos idées offrent des conseils pratiques à ceux qui se lancent dans l’aventure GraphQL, leur permettant d’exploiter ses avantages et de surmonter efficacement les défis.

Les limitations des API REST stimulent la demande pour une nouvelle approche technologique des API.

L'approche basée sur REST (Representational State Transfer) a été initialement proposée comme un ensemble de principes architecturaux pour la conception d'API Web. REST a évolué au cours des années 2000 et 2010 avec l'émergence du Web 2.0 comme meilleur moyen de mettre en œuvre une architecture orientée services (SOA) par rapport à d'autres technologies comme Common Object Request Broker Architecture (CORBA).

À mesure que le nombre de clients a augmenté en raison de l’adoption du mobile, la demande de données précises a augmenté. Cependant, les API basées sur REST entraînaient souvent une récupération excessive ou insuffisante des données, ce qui entraînait des inefficacités. Cette approche, illustrée par des applications comme Facebook, nécessitait souvent de nombreux appels d’API REST pour une seule mise à jour, augmentant le trafic réseau et compromettant les performances et l’expérience utilisateur.

GraphQL a été spécifiquement conçu pour répondre à ces limitations en offrant un schéma fortement typé et un moyen plus efficace d'interroger les données. Cela le rend particulièrement adapté aux cas d’utilisation où des données spécifiques sont nécessaires pour optimiser la bande passante du réseau. De plus, la capacité de GraphQL à introspecter le schéma permet une meilleure documentation et un meilleur outillage. Bien qu'une implémentation plus standardisée de REST aurait pu fournir une certaine concurrence, les fonctionnalités et avantages uniques de GraphQL en font un choix convaincant pour les architectures d'applications modernes qui sont distribuées et gourmandes en données.

La figure 1 montre une différence topologique entre la manière dont REST et GraphQL sont implémentés. Comme indiqué dans REST API vs GraphQL , « la principale différence entre GraphQL et les API REST est que GraphQL est un langage de requête, tandis que REST est un concept architectural pour les logiciels basés sur le réseau. » 

Meta a créé GraphQL en 2012 ( open-source 2015) pour améliorer les performances et la flexibilité de ses applications mobiles. Avant GraphQL, les applications mobiles de Meta étaient créées à l'aide d'une combinaison d'API RESTful et de code natif, ce qui rendait difficile la gestion de la large gamme d'appareils, de tailles d'écran et de conditions de réseau que les applications devaient prendre en charge. 

L’un des principaux défis auxquels ils étaient confrontés était que les API RESTful renvoyaient souvent la mauvaise quantité de données, parfois trop et parfois trop peu. Lorsque l'API renvoyait une grande quantité de données dont les applications mobiles n'avaient pas besoin, cela entraînait des temps de chargement lents et des performances médiocres. Lorsque l'API renvoyait trop peu de données, les applications mobiles devaient effectuer plusieurs requêtes auprès de différents points de terminaison pour récupérer toutes les données dont elles avaient besoin, ajoutant ainsi de la latence et de la complexité au processus.

Meta a développé GraphQL pour que n'importe quelle application puisse demander uniquement les données dont elle a besoin en une seule requête. Cela a permis d'optimiser le transfert de données entre les applications mobiles et les services backend, ce qui a entraîné des temps de chargement plus rapides et de meilleures performances. De plus, les fonctionnalités de typage puissantes et d'auto-documentation de GraphQL ont permis aux développeurs de comprendre et d'utiliser plus facilement l'API. 

GraphQL offre de puissantes fonctionnalités de récupération et de manipulation de données, offrant des avantages significatifs par rapport aux approches API traditionnelles. 

GraphQL dispose d'un schéma fortement typé qui garantit clarté et précision dans la définition de la structure et des types de données pouvant être interrogées à partir d'une API. Supposons que nous ayons une API pour une bibliothèque contenant des livres, des auteurs et des éditeurs. 

a) Schéma GraphQL : Dans GraphQL, un schéma fortement typé ressemblerait à la figure 2 ci-dessous : 

Les schémas fortement typés dans GraphQL offrent des avantages liés à la sécurité en permettant la validation des entrées, en empêchant la récupération excessive et insuffisante des données, en fournissant une documentation et un support d'outils clairs, en facilitant le contrôle des versions et en aidant à l'autorisation et au contrôle d'accès. Ces fonctionnalités améliorent la sécurité des API en réduisant le risque de vulnérabilités courantes et en garantissant une gestion appropriée des données et des accès.

Dans l’exemple illustré (Figure 2), le schéma définit les types de données pour les livres, les auteurs et les éditeurs, ainsi que leurs relations entre eux. Le schéma est fortement typé , ce qui signifie que chaque champ a un type de données spécifique, et les clients peuvent facilement introspecter le schéma pour découvrir les champs disponibles et leurs types.

b) Schéma REST : Dans REST, la définition du schéma serait vaguement typée comme indiqué dans la figure 3 ci-dessous : 

Ces points de terminaison renvoient des objets JSON représentant les livres, les auteurs et les éditeurs, mais le schéma lui-même n'est pas explicitement défini et est laissé à la compétence et à l'interprétation du programmeur. Les clients devront s’appuyer sur la documentation pour comprendre la structure des données.

GraphQL est devenu une meilleure alternative à REST et a le potentiel de devenir une approche privilégiée pour les entreprises envisageant une meilleure stratégie de données. En plus de résoudre les limitations de REST, il existe plusieurs autres raisons pour lesquelles GraphQL a évolué vers une nouvelle approche de la conception d'API. Bien que le tableau (Figure 4) puisse montrer les avantages de GraphQL par rapport à REST, GraphQL est mieux considéré comme une réponse à l’évolution d’Internet et des différentes applications plutôt que comme une réponse à l’identification des problèmes avec REST lui-même.

Bien que GraphQL offre de nombreux avantages par rapport aux API RESTful traditionnelles, son utilisation présente également certains défis. Les défis courants incluent :

1. Courbe d'apprentissage : Étant donné que la plupart des développeurs sont plus familiarisés avec REST, les organisations qui envisagent d’adopter GraphQL devront prévoir du temps pour que leurs équipes apprennent à l’utiliser efficacement. GraphQL nécessite une manière différente de penser la création et la consommation d'API et son adoption pourrait nécessiter des modifications de l'architecture d'application sous-jacente. Les développeurs peuvent avoir besoin d’apprendre de nouveaux concepts tels que les schémas, les résolveurs et les types, ainsi que de nouveaux outils et bibliothèques. Avec GraphQL, les clients ont plus de contrôle sur les données auxquelles ils peuvent accéder, ce qui peut rendre plus difficile la sécurisation des API. Des techniques telles que la validation des entrées, l’authentification et l’autorisation peuvent devoir être appliquées différemment qu’avec les API RESTful.
2. Mise en cache : La mise en cache peut être plus complexe avec GraphQL, car les clients peuvent demander des données différentes à chaque requête, ce qui rend plus difficile la mise en cache et la réutilisation des réponses.
3. Performance : Bien que GraphQL permette aux clients de demander uniquement les données dont ils ont besoin, il peut également permettre des requêtes plus complexes et gourmandes en ressources. Les API GraphQL peuvent rencontrer des problèmes de performances, notamment lors de l'interrogation de grands ensembles de données ou lorsqu'un nombre élevé de requêtes simultanées sont effectuées. Les développeurs doivent mettre en œuvre des stratégies telles que la limitation de la profondeur de la requête ou la garantie que les clients sont autorisés à accéder uniquement aux données spécifiques nécessaires.
4. Gestion des erreurs : GraphQL peut rendre la gestion des erreurs plus complexe car les erreurs peuvent être renvoyées dans le cadre de la réponse plutôt que sous la forme d'un code d'état HTTP distinct.
5. Test : Les tests avec GraphQL présentent des défis en raison de la complexité des requêtes, du manque d’approches de test standardisées, de l’évolution du schéma et de la validation des requêtes pendant l’exécution. Les développeurs doivent investir du temps pour trouver des cadres et des outils de test adaptés pour relever ces défis. Les développeurs doivent garantir une couverture de test complète en sélectionnant des outils appropriés et en tenant compte de l'évolution du schéma pour tester efficacement les API GraphQL et garantir leur fonctionnalité et leur stabilité.
6. Surveillance : La surveillance des API GraphQL peut être difficile en raison de la complexité des requêtes, du manque de journalisation et de mesures standardisées et du potentiel de problèmes de performances. La nature dynamique des requêtes GraphQL rend plus difficile la prévision et la surveillance de la structure et de la taille des données demandées. L’absence d’outils de surveillance standardisés spécifiques aux API GraphQL rend difficile l’obtention d’informations sur les performances des requêtes GraphQL, le suivi des erreurs et l’état de l’API. Les développeurs doivent adopter des outils et des pratiques de surveillance spécialisés capables de gérer les caractéristiques uniques de GraphQL, garantissant des performances efficaces et un fonctionnement fiable. 

GraphQL est un outil puissant qui peut être utilisé dans une large gamme d'applications, de la création d'API à l'alimentation d'applications mobiles. Sa flexibilité et sa capacité à unifier les sources de données le rendent parfaitement adapté à une variété de modèles d'utilisation différents.

1. Créer des API efficaces : L’une des principales utilisations de GraphQL est de créer des API qui peuvent être utilisées par des applications Web et mobiles. GraphQL fournit un moyen flexible et puissant de définir et d'accéder aux données, ce qui le rend parfaitement adapté à la création d'API qui doivent prendre en charge un large éventail de clients et de cas d'utilisation.
2. Récupération et manipulation des données : GraphQL peut être utilisé pour récupérer et manipuler des données à partir de diverses sources, notamment des bases de données, des services cloud et d'autres API. En fournissant un moyen unifié d’accéder aux données, GraphQL peut aider à simplifier le processus de création et de maintenance d’applications pilotées par les données.
3. Cas d'utilisation en temps réel : GraphQL est bien adapté aux cas d'utilisation en temps réel, car les clients peuvent s'abonner aux mises à jour de données spécifiques et recevoir des notifications lorsque les données changent. Cela peut être utilisé dans des applications telles que le chat, la diffusion en direct, les tableaux de bord en temps réel, etc.
4. Microservices : GraphQL peut être utilisé pour créer une architecture flexible et faiblement couplée qui permet à différents microservices de communiquer entre eux de manière cohérente et bien définie.
5. Du back-end au front-end : GraphQL peut être utilisé pour créer une architecture back-end-for-front-end (BFF), qui permet à différents clients front-end d'accéder aux données et aux services de manière cohérente et efficace.
6. Développement mobile : GraphQL peut être utilisé pour alimenter les applications mobiles, en fournissant un moyen d'accéder aux données et aux services de manière cohérente et efficace, quelle que soit la plate-forme ou l'appareil. 

Il existe des motivations évidentes pour lesquelles nous avons besoin de GraphQL, comme le montrent les déploiements industriels suivants :

Netflix a résumé son parcours GraphQL en 2020 avec une série de blogs en deux parties qui est une lecture incontournable pour tout praticien GraphQL. L'étude de cas qu'ils ont présentée était le système Studio Edge reprenant leurs API de studio et les réarchitectant pour GraphQL. L'API Studio de Netflix est utilisée par ses équipes de contenu pour gérer et surveiller la production, la post-production et la distribution d'émissions de télévision et de films. L'API donne accès à une grande quantité de données, notamment des métadonnées sur les titres, des informations sur les talents, etc.

Initialement, l’API Studio a été construite à l’aide d’une architecture RESTful traditionnelle, avec des points de terminaison qui renvoyaient des données au format JSON. Cependant, à mesure que l’API s’est développée et que le nombre de clients y accédant a augmenté, il est devenu évident qu’une solution plus efficace était nécessaire.

Netflix a commencé à explorer GraphQL comme solution potentielle pour l’API Studio. Ils ont commencé par créer un graphique organisé pour l’API Studio. Ils ont identifié plusieurs avantages clés, notamment la possibilité de réduire l’utilisation du réseau, de simplifier l’accès aux données et d’améliorer les performances en permettant aux clients de demander uniquement les données dont ils ont besoin.

Netflix a également été confronté à des défis uniques lors de l'adoption de GraphQL pour l'API Studio, notamment en ce qui concerne la gestion de la complexité du schéma et la garantie que les clients ne pouvaient accéder qu'aux données qu'ils étaient autorisés à voir.

Pour relever ces défis, Netflix a développé une solution personnalisée appelée « Netflix GraphQL Federation », qui utilise la spécification Apollo Federation pour diviser le schéma de l'API Studio en éléments plus petits et plus faciles à gérer. Ils ont également mis en place un système de gestion des autorisations et du contrôle d’accès, qui leur permet de restreindre l’accès des clients à certaines parties du schéma.

Dans le blog, ils ont également publié l'évolution de leur architecture API, d'un monolithe à une passerelle fédérée. La figure 5 est une adaptation de l’image de leur blog.

Nous pensons qu’il manque une autre approche qui est peut-être répandue dans l’industrie mais qui n’est pas formalisée.

On pourrait combiner la couche agrégée de passerelle et la passerelle fédérée de la figure 5 comme indiqué ci-dessous :

Chaque icône d'engrenage représente essentiellement une instance GraphQL éphémère et fédérée (alias acteur de passerelle) qui peut être instanciée en temps réel (même sur une base par transaction) à la périphérie, c'est-à-dire topologiquement proche des clients et se connecter aux microservices via un transport API sécurisé. Cette combinaison remplace essentiellement la couche d’agrégation de passerelle, ou la couche fédérée, par des acteurs de passerelle distribués qui combinent le meilleur des deux fonctionnalités. Nous appelons cette architecture d'acteurs de passerelle GraphQL distribuée comme illustré dans la figure 7.

PayPal est sur le chemin de GraphQL depuis2018 lorsqu'ils l'ont intégré à leur application Checkout. Leur principale préoccupation avec REST, similaire à celle de Meta, était que les principes de conception ne sont pas optimisés pour les applications Web et mobiles et leurs utilisateurs. Les applications clientes effectuaient de nombreux allers-retours entre le client et le serveur, prenant environ 700 ms pour récupérer les données. Cela a entraîné un temps de rendu plus lent, une frustration des utilisateurs et des taux de conversion plus faibles. Pour l'application de paiement PayPal a découvert que les développeurs d'interface utilisateur (UI) passaient moins d'un tiers de leur temps à créer l'interface utilisateur tandis que le temps restant était consacré à déterminer comment récupérer et traiter les données.

Les autres technologies prises en compte par l’équipe d’ingénierie de PayPal étaient les API d’orchestration et Bulk REST. La création d’une API d’orchestration entraînerait une récupération excessive et le couplage des clients au serveur. PayPal a conclu qu’au fil du temps, cette approche peut rendre l’API lourde, compliquée et servir à plusieurs fins. Leur expérience Bulk REST s’est également avérée infructueuse. Bien que cela ait libéré l’équipe d’ingénierie de la nécessité de modifier les API d’orchestration, cela exigeait que leurs clients aient une connaissance approfondie du fonctionnement des API.

La première expérience de PayPal utilisant GraphQL pour créer un nouveau produit était un SDK mobile pour intégrer PayPal Checkout dans des applications. Une semaine après avoir évalué GraphQL, l’équipe d’ingénierie a décidé de l’utiliser pour son nouveau produit. Même si l'API n'était pas prête, ils ont quand même pu terminer le produit plus tôt que prévu, sans avoir besoin de connaissances spécifiques à PayPal. Les développeurs ont pu rapidement créer une application efficace et conviviale, convaincant l'équipe d'ingénierie d'adopter pleinement GraphQL dans leur pile technologique. 

Starbuck a fait appel à un tiers pour développer son Application Web progressive (PWA).

L’équipe a été chargée de créer un système de commande capable de s’adapter efficacement à une logique commerciale complexe. Les clients étant en mesure de personnaliser leurs commandes, l’équipe de développement a dû s’assurer que le système pouvait prendre en charge plusieurs instances de logique métier unique, en envoyant les bonnes données au bon endroit et au bon moment.

GraphQL a permis à l'équipe de créer une API efficace avec mise en cache et rendu côté serveur pour améliorer les fonctionnalités hors ligne. L’équipe a également utilisé React pour intégrer des animations créant une expérience utilisateur dynamique et convaincante.

L’objectif du Bureau du CTO F5 était de comprendre comment nous pouvions utiliser GraphQL au sein de l’écosystème F5. Nous avons deux projets en cours explorant l'utilisation de GraphQL.

La suite de gestion des tests (TMS) proposée par F5 offre aux clients la possibilité de tester les points de terminaison ou les clients de leurs propres systèmes et de voir s'il s'agit d'humains ou de robots.

Il s'agissait d'un projet interne visant à rationaliser le développement et les tests du logiciel TMS. L’objectif principal était d’extraire les données JSON piégées dans la base de données SQL existante, de les convertir en données graphiques et d’implémenter une API GraphQL pour les requêtes.

Cela était nécessaire car la base de données actuelle pose des défis, notamment le « problème JSON-blob » qui résulte du stockage des métadonnées sous forme d'objets JSON dans une base de données tabulaire. L’analyse et la gestion de ces objets sont intrinsèquement coûteuses et inefficaces. De plus, les blobs JSON, en raison de leur nature graphique, contiennent des données précieuses qui peuvent encore améliorer les produits et la sécurité de F5. En passant à une base de données graphique dirigée, les blobs JSON peuvent être analysés et gérés efficacement avec des relations dirigées, optimisant ainsi le transfert et l'utilisation des données. 

Les résultats sont encourageants. En identifiant les tables de la base de données relationnelle TMS contenant des blobs JSON, nous avons déterminé que le passage à une GraphDB et l'utilisation de GraphQL pourraient augmenter considérablement notre visibilité sur le système. 

La figure 9 montre les évolutions ou choix de mise en œuvre possibles pour ce projet. Chaque choix a ses propres implications.

L'option 1 a le moins d'impact sur l'interface utilisateur car le client n'a pas besoin de modifier. Un mode hybride, comme dans les options 1 ou 2, peut bien fonctionner selon la situation, surtout s'il y a un plus petit nombre de colonnes avec des objets JSON. En plus de cela, le schéma dérivé de chaque JSON serait également petit.

Mais lors de la planification de cela, nous avons réalisé que les objets JSON nécessitaient un contexte qui était stocké dans d'autres colonnes de la base de données SQL. La taille du schéma stocké dans chaque objet JSON était également assez importante. Cela aurait créé plus de travail pour maintenir la base de code. Ainsi, après un examen attentif, nous avons décidé de réorganiser l’application pour prendre en charge GraphQL et Neo4J comme indiqué dans l’option 3.

CloudGraph est une API GraphQL universelle open source gratuite et un outil de gestion de la posture de sécurité dans le cloud (CSPM) pour AWS, Azure, GCP et Kubernetes (K8s). L'objectif du projet est d'utiliser CloudGraph pour créer un « plugin CloudGraph » (Figure 10) sur lequel les données F5 Distributed Cloud (F5XC) apparaîtront, permettant une meilleure visibilité des ressources cloud connectées à l'aide de F5 Distributed Cloud.

Notre objectif est de nous intégrer à CloudGraph pour acquérir une compréhension approfondie de la technologie et de créer de futures intégrations CloudGraph, des informations et des API GraphQL pour les données F5XC.

Après avoir intégré le fournisseur F5XC personnalisé dans la plateforme CloudGraph et utilisé la capacité de création de relations de la plateforme, nous aurons une meilleure visibilité des ressources cloud connectées à l'aide de F5XC et de leurs relations avec d'autres clouds. Nous pouvons ensuite générer des requêtes complexes sur des ressources réparties sur plusieurs clouds pour le même locataire. Cela nous permettra de fournir aux parties prenantes un aperçu complet de F5XC et d'explorer une intégration plus approfondie de CloudGraph pour des plugins GraphQL supplémentaires et des informations personnalisées pour les opérations cloud pertinentes pour F5 et ses clients.

Sur la base des initiatives susmentionnées, notre exploration initiale s’est inscrite dans la continuité des expériences décrites dans les études de cas présentées précédemment.

Les perceptions initiales concernant la supériorité de GraphQL sur REST en termes de sécurité ont été démystifiées, car GraphQL, comme toute autre technologie, comporte ses propres risques s'il n'est pas implémenté correctement. Il est important de reconnaître que GraphQL n’est pas intrinsèquement plus sécurisé que les autres technologies. Une mise en œuvre appropriée et le respect des meilleures pratiques sont essentiels pour garantir la sécurité des API GraphQL. En dissipant ce mythe, nous pouvons aborder GraphQL avec une compréhension réaliste de ses considérations de sécurité et prendre les mesures appropriées pour atténuer tout risque potentiel.

GraphQL fournit aux développeurs un outil puissant appelé introspection, qui leur permet de demander des informations sur le schéma utilisé par un service GraphQL. Cet outil permet aux développeurs d'en savoir plus sur le service et sa structure. Cependant, l’introspection comporte des risques. L'activation de l'introspection dans un service GraphQL de production signifie que les informations sensibles au sein du schéma sont également accessibles. Cela présente un risque important, car les utilisateurs malveillants peuvent exploiter l’introspection pour obtenir des données sensibles et potentiellement causer des dommages. De plus, l’introspection donne à ces utilisateurs la possibilité d’identifier facilement les opérations potentiellement nuisibles, car ils peuvent visualiser l’intégralité du schéma et déterminer les requêtes à exécuter. Les conséquences d’une telle fuite peuvent être désastreuses, selon la nature du schéma et des données qu’il contient.

Atténuation : Une solution pour atténuer les risques d’introspection est de la désactiver dans les API de production à l’aide de différents frameworks. En désactivant l’introspection, les développeurs perdent certaines des fonctionnalités pratiques qu’elle offre. Cependant, pour retrouver sa convivialité, les développeurs peuvent enregistrer le schéma GraphQL de l'API de production avec des outils comme GraphOS. Cela leur permet de conserver un accès contrôlé au schéma et à ses informations.

L’injection SQL est une attaque largement reconnue et répandue qui présente des risques allant de la manipulation des données à la suppression complète de la base de données. Cette attaque simple tire parti de la concaténation de chaînes, permettant à un attaquant d'insérer du code exécutable dans l'entrée, accordant un accès non autorisé à la base de données et permettant des modifications malveillantes. Il est intéressant de noter que ce vecteur d’attaque ne se limite pas aux seules bases de données SQL, mais peut également affecter les bases de données graphiques comme Neo4j. Neo4j utilise le langage de requête Cypher, qui ressemble à SQL et hérite de ses vulnérabilités. Ce type d’attaque, connu sous le nom d’injection Cypher, exploite les similitudes mais bénéficie également des solutions existantes sans avoir besoin de nouvelles inventions.

Atténuation : Les contre-mesures incluent la désinfection des entrées utilisateur pour détecter et empêcher l’exploitation et l’utilisation de la paramétrisation pour abstraire les entrées utilisateur de la création directe de requêtes. Ces mesures atténuent efficacement le risque d’attaques par injection. Il est crucial de résoudre ce problème de sécurité dans les implémentations GraphQL, mais heureusement, des solutions bien connues et facilement implémentables sont disponibles. 

La superposition d'une API GraphQL sur une API REST peut entraîner des vulnérabilités de falsification de requête côté serveur (SSRF). Les attaquants peuvent exploiter cela en modifiant les paramètres envoyés à l'API REST via le proxy GraphQL. Si aucune API ne valide les paramètres pour des appels spécifiques, les attaquants prennent le contrôle du système backend. Par exemple, l'ajout de « /delete » à un ID utilisateur dans une requête GraphQL peut entraîner une suppression involontaire de données lors de leur transmission à l'API REST.

Atténuation : Bien que cette vulnérabilité soit une préoccupation valable, elle peut être efficacement résolue en définissant des types dans le schéma GraphQL et en validant soigneusement les paramètres avant de les envoyer à des API ou services externes. Il est important de noter que cette vulnérabilité, ainsi que d’autres associées à GraphQL, provient de problèmes d’implémentation plutôt que de problèmes inhérents à GraphQL lui-même. De tels problèmes surviennent lorsque GraphQL est mal utilisé en raison d’une mentalité à court terme, malgré les promesses très prometteuses de cette technologie.

Les vulnérabilités d’authentification sont un vecteur d’attaque répandu sur divers systèmes, y compris GraphQL. La capacité de GraphQL à envoyer plusieurs requêtes ou mutations dans une seule requête l'expose aux attaques par lots, qui impliquent des méthodes de force brute.

Le premier type d’attaque consiste à forcer les mots de passe de connexion. Les attaquants envoient une requête avec de nombreuses mutations contenant des paires d’informations d’identification de connexion. Étant donné que GraphQL autorise de nombreuses mutations dans une seule requête, cette attaque contourne les contrôles de limitation de débit et permet la création d'une session en forçant brutalement les mots de passe.

Le deuxième type d’attaque fonctionne de manière similaire mais cible une forme populaire d’authentification à deux facteurs (2FA) appelée mot de passe à usage unique (OTP). Une seule demande est envoyée avec plusieurs mutations, chacune contenant un identifiant de connexion valide associé à une variante OTP différente. Si l’une des mutations inclut l’OTP correct, la demande sera authentifiée et une session sera établie.

Atténuation : Pour remédier à ces vulnérabilités, il faut adopter une approche globale, car il n’existe pas de solution infaillible. Les développeurs jouent un rôle crucial en adoptant des pratiques de codage sécurisées et en mettant l’accent sur la perspective de la logique métier. Côté serveur Web, il est essentiel de mettre en œuvre des mesures telles que la limitation des tentatives de connexion et la validation des saisies des utilisateurs. De plus, une attention particulière doit être accordée aux demandes d’analyse de mutations multiples, car une tentative de connexion légitime n’implique généralement pas plus d’une mutation.

Ces attaques impliquent de submerger le service GraphQL avec un trafic excessif, le rendant incapable de gérer les requêtes des utilisateurs légitimes et provoquant potentiellement des pannes de serveur. Les attaques DoS peuvent être exécutées via des requêtes GraphQL récursives ou en envoyant des requêtes volumineuses.

Dans le scénario de requête récursive, les attaquants exploitent la nature cyclique des définitions de schéma GraphQL. Par exemple, si le schéma inclut les types d’auteur et de livre, un attaquant peut interroger à plusieurs reprises l’auteur et le livre dans une boucle, submergeant le serveur d’ appels récursifs et perturbant son fonctionnement.

Alternativement, les attaquants peuvent émettre des requêtes qui demandent une grande quantité de données à la base de données. Par exemple, une requête peut récupérer de nombreux auteurs et tous leurs livres associés. Une demande de données aussi massive peut considérablement ralentir ou faire planter le système .

Atténuation : Il existe plusieurs solutions pour atténuer ce problème. La première approche consiste à définir un délai d’expiration pour les requêtes, empêchant les utilisateurs de faire des requêtes dépassant une durée spécifiée. Cependant, cela ne résout peut-être pas entièrement le problème, car des dommages peuvent toujours survenir dans le délai imparti. Une autre solution consiste à imposer des limites à la profondeur et à la complexité des requêtes. Les requêtes qui dépassent la profondeur ou la complexité désignée, qui s'écarte de la définition du schéma, peuvent être rejetées. Enfin, la mise en œuvre d’une limitation des utilisateurs peut s’avérer efficace. Si un utilisateur envoie un ensemble important ou consécutif de requêtes, son accès au serveur peut être temporairement refusé jusqu'à ce que le serveur soit prêt à gérer des requêtes supplémentaires.

Il existe plusieurs modèles de déploiement pour GraphQL, comme indiqué, chacun avec son propre ensemble de compromis et de considérations. Certains des modèles les plus courants incluent :

Il s'agit du modèle le plus simple et le plus courant pour déployer une API GraphQL. Dans un déploiement monolithique, le serveur GraphQL, la base de données et tous les autres services nécessaires sont tous déployés ensemble en tant qu'unité unique. Cela peut faciliter la prise en main de GraphQL, mais peut devenir difficile à faire évoluer et à maintenir à mesure que l'application se développe. 

Les monolithes composés font référence à l'architecture dans laquelle une application monolithique est construite à l'aide d'une combinaison de services monolithiques et de microservices avec GraphQL agissant comme couche API (Figure 12). Dans ce modèle, au lieu de décomposer l'ensemble du système en microservices distincts, l'application est initialement développée sous forme de monolithes distincts, qui encapsulent toutes les couches de logique métier et d'accès aux données. 

Au sein de cette structure monolithique, GraphQL est implémenté en tant que couche API, permettant aux clients de demander et de récupérer des données à partir de différents microservices sous-jacents. Cela signifie que même si l'application reste monolithique du point de vue du déploiement, elle utilise GraphQL comme moyen de composer des données à partir de divers services et de les présenter aux clients de manière flexible et efficace.

Ce modèle offre des avantages tels qu'un développement et un déploiement simplifiés, ainsi que la possibilité d'exploiter les puissantes capacités d'interrogation et de récupération de données de GraphQL. Il permet aux développeurs d'adopter progressivement l'architecture des microservices tout en bénéficiant de la flexibilité et de la facilité d'utilisation offertes par GraphQL. 

Les graphiques fédérés dans les modèles de déploiement GraphQL impliquent la combinaison de plusieurs services GraphQL, appelés sous-graphiques, dans un seul schéma GraphQL unifié. Chaque sous-graphique représente un domaine ou un microservice distinct avec ses propres données et fonctionnalités. Cette architecture utilise une passerelle centrale qui achemine les requêtes des clients vers le sous-graphe approprié en fonction des champs demandés. En fédérant ces sous-graphes, les développeurs peuvent créer un graphe cohérent dans lequel les clients peuvent interroger et parcourir de manière transparente différents services.

Cette approche favorise la modularité, l’évolutivité et le développement indépendant des services, ce qui améliore les performances et la flexibilité pour la création d’API GraphQL. Les sous-graphes fédérés (Figure 13) offrent un moyen puissant de composer des données à partir de divers services et de créer une architecture distribuée et évolutive.

Les graphiques hybrides (Figure 14) dans les modèles de déploiement GraphQL combinent des sous-graphes fédérés et des schémas non fédérés via des techniques de couture. Cette approche permet aux organisations d’intégrer les API GraphQL existantes ou les systèmes hérités avec des microservices fédérés, ce qui donne lieu à une API GraphQL unifiée qui bénéficie des deux approches. En fusionnant les schémas et en résolvant les relations entre les types et les champs, l'architecture graphique hybride offre flexibilité, modularité et évolutivité.

Le modèle de graphique hybride offre aux organisations la possibilité d’adopter progressivement la fédération tout en exploitant leurs ressources existantes. Il permet l’intégration transparente de sous-graphes fédérés et de schémas non fédérés, répondant à diverses exigences et favorisant l’interopérabilité. Cette approche permet aux organisations de créer des API GraphQL complètes qui peuvent évoluer et s’adapter à l’évolution des besoins. En combinant les atouts des services fédérés et non fédérés, les graphiques hybrides offrent une solution flexible et puissante pour créer des déploiements GraphQL.

Les défis liés aux graphiques hybrides dans les déploiements GraphQL incluent la gestion de la complexité des schémas fusionnés, la gestion des éventuelles surcharges de performances, la garantie de la cohérence et de l'intégrité des données, la gestion de l'évolution et du contrôle de version du système, et la navigation dans les complexités de la surveillance et du débogage dans une architecture distribuée. Ces défis nécessitent une planification minutieuse, une optimisation et des pratiques de développement robustes pour les surmonter et garantir le bon fonctionnement des déploiements de graphes hybrides. 

Ce modèle implique le déploiement de l'API GraphQL sous la forme d'un ensemble de fonctions sans serveur, telles que AWS Lambda ou Google Cloud Functions. Cela peut être un moyen rentable et évolutif de déployer une API GraphQL, mais peut également introduire une latence supplémentaire et augmenter la complexité de l'architecture.

Le routage sans serveur présente de nombreux défis. L’un des problèmes réside dans la connexion transparente des sous-graphes distribués à mesure que l’application se développe. La coordination de plusieurs équipes et déploiements peut devenir complexe, ce qui rend difficile la gestion et la mise à l'échelle efficaces des sous-graphes. Assurer la cohérence et la synchronisation des données entre ces sous-graphiques constitue un autre obstacle. La surveillance et le débogage dans un environnement sans serveur distribué peuvent être plus difficiles, nécessitant des mécanismes de journalisation et de gestion des erreurs appropriés. De plus, la gestion du contrôle d’accès et de l’autorisation sur plusieurs fonctions et sous-graphes sans serveur pose des défis. Relever ces défis est essentiel pour le bon fonctionnement et l’évolutivité d’un déploiement GraphQL sans serveur.

Dans un modèle de déploiement de périphérie pour les API GraphQL, l’API est placée plus près des clients à l’aide d’un service CDN. Cela apporte plusieurs avantages, notamment une latence plus faible pour des réponses plus rapides, une charge réduite sur le serveur d’origine et une protection contre les attaques DDoS.

En répartissant l’infrastructure API sur des serveurs périphériques dans le monde entier, elle peut gérer le trafic plus efficacement et offrir une meilleure expérience utilisateur à l’échelle mondiale. Les capacités de mise en cache et de filtrage du CDN contribuent à améliorer l'évolutivité et à garantir la disponibilité de l'API, même face à un trafic important ou à des attaques malveillantes. Les déploiements Edge ont le potentiel d'optimiser les performances et la fiabilité d'une API en exploitant le réseau de serveurs des CDN. 

Les technologies GraphQL sont suffisamment matures pour être adoptées par les entreprises traditionnelles. Bien que le Hype Cycle for APIs 2022 de Gartner indique que nous sommes encore à plusieurs années d'une adoption généralisée, nous avons maintenant atteint un tournant critique où les outils nécessaires sont déjà en place. Bien que GraphQL soit encore relativement nouveau, il a évolué au point de pouvoir répondre aux besoins des entreprises établies à grande échelle.

La maturité des technologies GraphAPI est enracinée dans le nombre croissant d’entreprises adoptant GraphQL et d’autres technologies de bases de données graphiques. À mesure que de plus en plus d’entreprises adoptent ces technologies, les outils et les ressources nécessaires pour les prendre en charge deviennent de plus en plus disponibles, ce qui permet à d’autres entreprises de suivre plus facilement leur exemple. De plus, les avantages des technologies GraphAPI, tels que l’amélioration des requêtes de données et la réduction de la complexité, sont de plus en plus largement reconnus, ce qui favorise encore davantage leur adoption parmi les entreprises.

En tant qu’industrie, nous devons reconnaître l’importance des technologies GraphAPI telles que GraphQL et leur potentiel à surmonter les limitations de REST. Les entreprises ne doivent pas négliger le besoin urgent d’investir dans GraphQL et de le comprendre, notamment en termes de modélisation des données, de diversité et d’opacité. Bien qu’il soit facile de devenir amoureux des fonctionnalités et du potentiel de GraphQL, nous devons également reconnaître le creux potentiel de la désillusion après avoir atteint un sommet avec des attentes gonflées. Les fournisseurs doivent donner la priorité à l’amélioration de leurs produits pour prendre pleinement en charge GraphQL, tandis que l’informatique d’entreprise, y compris les fournisseurs, doit identifier les données qui bénéficieraient de l’exposition de GraphQL pour améliorer la productivité.

Les clients doivent donner la priorité à la compréhension de leurs données et reconnaître qu’une entreprise moyenne fonctionne différemment des hyperscalers qui ont introduit GraphQL à l’origine. Travaillons ensemble pour adopter GraphQL comme modèle d’architecture logicielle efficace et faire avancer l’industrie vers une meilleure productivité et une meilleure innovation.

Télécharger le rapport