GraphQL est un langage de requête open source pour les API qui peut récupérer des données à partir de plusieurs sources en un seul appel d'API. Il agit également comme un environnement d'exécution côté serveur pour répondre aux requêtes avec des données existantes. GraphQL donne la priorité à la fourniture au client uniquement des données demandées tout en fournissant une description complète des données API, et facilite la mise à l'échelle et l'évolution des API.
GraphQL a été conçu dans un souci de flexibilité, de rapidité et de développeurs. Avec GraphQL, les développeurs peuvent créer des API comme ils le souhaitent, puis utiliser une spécification GraphQL pour garantir que les API sont fonctionnelles pour les clients.
L’un des principaux concepts d’une requête GraphQL est que les données que vous recevez en retour sont prévisibles. Plutôt que des chaînes de code excédentaires, ce qui est renvoyé est exactement ce qui est demandé. Cette récupération de données déclarative est particulièrement utile sur les appareils mobiles, où la bande passante est limitée. Les applications qui utilisent GraphQL sont également stables et rapides car elles contrôlent les données demandées et reçues, plutôt que le serveur. Ils sont également rapides même sur des connexions réseau lentes, car une seule requête peut renvoyer plusieurs éléments demandés à la fois.
S'appuyant sur la simplification des données de GraphQL, les API sont organisées par types et champs au lieu de points de terminaison. Cela signifie que toutes les données sont accessibles à partir d'un seul point de terminaison, ce qui permet aux applications de demander uniquement ce qui est nécessaire. En réduisant la complexité opérationnelle, GraphQL s'intègre dans le flux de travail d'une solution de connectivité API simplifiée.
En 2012, Meta (alors Facebook) avait besoin d'une API de récupération de données suffisamment puissante pour ses applications mobiles Facebook . Sous la direction de Lee Byron, Facebook a développé GraphQL comme un moyen de simplifier la récupération de données, en particulier du point de vue des concepteurs et des développeurs de produits. GraphQL a d'abord été utilisé en interne par Facebook, puis publié publiquement et open source en 2015. Suivant la trajectoire de nombreux autres projets open source, le projet GraphQL a migré en 2019 vers sa propre fondation GraphQL , hébergée par la Linux Foundation .
GraphQL a été conçu comme une alternative à l'architecture REST . Les API REST standard nécessitent le chargement d'informations à partir de plusieurs URL via des requêtes HTTP GET distinctes. Avec les API GraphQL, toutes les données sont récupérées via une seule requête POST. Alors que REST et GraphQL renvoient tous deux des réponses au format JSON, GraphQL se concentre sur la rationalisation et la consolidation des données.
GraphQL prend en charge les demandes de données à granularité fine et donne aux clients plus de contrôle sur les informations envoyées. Le client envoie une requête GraphQL sous la forme d'une requête POST à laquelle le serveur renvoie une réponse au format JSON. GraphQL ne nécessite pas d'architecture d'application spécifique, est déployable dans plusieurs environnements (y compris un environnement de développement intégré [IDE]) et peut être utilisé avec des outils de gestion d'API existants ou sur des API REST existantes.
Certains termes clés de GraphQL incluent :
Une caractéristique unique de GraphQL est que les réponses reflètent la structure de la requête (qui est elle-même définie par le schéma). Cela simplifie l’analyse pour le client car le format de la réponse du serveur est entièrement prévisible.
La nature hiérarchique de GraphQL suit les relations entre les objets et fonctionne bien dans les interfaces utilisateur hiérarchiques. Il est également fortement typé, ce qui signifie que chaque niveau de requête correspond à un type. Ces types définissent ensuite un ensemble de champs. Ceci est similaire à SQL, où des messages d’erreur descriptifs sont affichés avant de terminer une requête.
Les résolveurs sont les modules architecturaux clés qui connectent les champs, les arêtes, les mutations, les requêtes et les abonnements GraphQL aux sources de données (et aux microservices).
Vous pouvez apprendre à créer des résolveurs pour les sources de données AWS dans ce didacticiel GraphQL .
Une chose qui rend les requêtes GraphQL uniques sont les réponses en miroir. Les données renvoyées par une requête deviennent prévisibles, car vous savez qu’elles correspondront à la forme de la requête API. Lorsque la forme des données renvoyées suit la requête du client, les serveurs deviennent simplifiés.
L’un des principaux avantages de GraphQL est que des extensions sont disponibles pour fournir des fonctionnalités qui ne sont pas disponibles dans REST. Les autres avantages de GraphQL sont les suivants.
Un schéma GraphQL définit une source unique de vérité dans les applications GraphQL, fournissant un emplacement principal où toutes les données sont décrites. Bien que le schéma GraphQL soit généralement défini sur le serveur, les clients peuvent toujours interroger et écrire des données en fonction du schéma.
Dans les architectures REST, le surextraction peut rapidement devenir un problème : l'application (backend) définit les données disponibles pour chaque ressource et les renvoie toutes dans sa réponse, même si le client (frontend) n'a besoin que d'un seul élément. Les appels GraphQL se produisent en un seul trajet et fournissent aux clients les données demandées sans aucune récupération excessive.
Étant donné que les types de données sont fortement définis, la communication entre le client et le serveur est plus claire dans GraphQL que dans REST. Cette structure sous-jacente signifie également que les clients complexes ne sont pas nécessaires pour appeler un serveur GraphQL. Pour en savoir plus et voir le code en action, lisez les informations sur les clients et les serveurs sur la page officielle de GraphQL .
API Federation, un ensemble de principes et d'outils de conception, permet d'exposer des services dans un contexte délimité en tant qu'API cohérente pour les utilisateurs, tout en permettant aux services dans ce contexte d'évoluer sans restrictions. GraphQL offre une méthode pour fédérer l'ensemble de l'API et évoluer sans casser les requêtes précédentes, ce qui est alors évolutif - et cette évolutivité est l'une des raisons pour lesquelles GraphQL est utilisé par de nombreuses entreprises.
La nature introspective de GraphQL permet de récupérer le schéma GraphQL à partir d'une API GraphQL. Les clients peuvent également demander une liste des types de données disponibles, ce qui est idéal pour générer automatiquement de la documentation et pour tester ou récupérer des schémas à partir de plusieurs microservices.
Bien qu’il existe de nombreuses raisons d’adopter GraphQL, il existe également quelques inconvénients à connaître. Par exemple, tout n’est pas prêt à l’emploi : des bibliothèques spéciales sont nécessaires pour utiliser l’API de quelqu’un d’autre. Et, globalement, GraphQL nécessite un support d’outils plus lourd que REST.
Les inconvénients de GraphQL par rapport à REST sont les suivants.
Pour les développeurs habitués aux API REST, GraphQL s'accompagne d'une courbe d'apprentissage plus raide. Cela peut également modifier le flux de travail : les équipes API utilisant GraphQL doivent également écrire des schémas GraphQL maintenables. Cela dit, si vous démarrez à zéro, GraphQL peut être facile à apprendre et à utiliser car les requêtes et les réponses ont la même structure.
GraphQL peut nécessiter de nouvelles stratégies de gestion des API, tandis que les API REST ont tendance à s'intégrer dans les modèles de gestion des API existants. Il est important d’en tenir compte, car l’ajout d’une nouvelle stratégie de gestion des API peut augmenter les dépenses globales.
La mise en cache est moins simple dans GraphQL que dans REST, où les requêtes utilisent généralement une méthode HTTP (GET, POST, PUT ou DELETE). Une requête GraphQL standard est POST, qui ne peut pas être mise en cache au niveau HTTP. La mise en cache peut également devenir complexe dans GraphQL, car le fait d’avoir un seul point de terminaison signifie que l’URL de ce point de terminaison produit plusieurs réponses variables non mises en cache (bonnes pour la récupération de données, mauvaises pour la mise en cache). Les développeurs de serveurs finissent alors par émettre des requêtes différentes, même si chacune opère au sein du même objet. Cela dit, de nombreuses bibliothèques GraphQL offrent des mécanismes de mise en cache prêts à l’emploi.