View a markdown version of this page

Pourquoi utiliser GraphQL plutôt que REST ? - AWS AppSync GraphQL

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Pourquoi utiliser GraphQL plutôt que REST ?

REST est l'un des styles architecturaux fondamentaux des API Web. Cependant, à mesure que le monde devient plus interconnecté, la nécessité de développer des applications robustes et évolutives deviendra une question de plus en plus pressante. Bien que REST soit souvent utilisé pour créer des API Web, les implémentations RESTful présentent plusieurs inconvénients récurrents qui ont été identifiés :

  1. Demandes de données  : à l'aide des API RESTful, vous demandez généralement les données dont vous avez besoin via des points de terminaison. Le problème survient lorsque vous avez des données qui ne sont peut-être pas aussi bien emballées. Les données dont vous avez besoin peuvent se trouver derrière plusieurs couches d'abstraction, et la seule façon de les récupérer est d'utiliser plusieurs points de terminaison, ce qui implique de faire plusieurs demandes pour extraire toutes les données.

  2. Extraction et sous-extraction  : pour aggraver les problèmes liés aux requêtes multiples, les données de chaque point de terminaison sont définies de manière stricte, ce qui signifie que vous renverrez toutes les données définies pour cette API, même si vous ne le souhaitez pas techniquement.

    Cela peut entraîner une extraction excessive, ce qui signifie que nos requêtes renvoient des données superflues. Par exemple, supposons que vous demandiez des données sur le personnel de l'entreprise et que vous souhaitiez connaître les noms des employés d'un service donné. Le point de terminaison qui renvoie les données contiendra les noms, mais il peut également contenir d'autres données telles que le titre du poste ou la date de naissance. L'API étant fixe, vous ne pouvez pas simplement demander les noms ; le reste des données est fourni avec.

    La situation inverse dans laquelle nous ne renvoyons pas suffisamment de données est appelée sous-extraction. Pour obtenir toutes les données demandées, vous devrez peut-être effectuer plusieurs demandes auprès du service. Selon la manière dont les données étaient structurées, vous pourriez rencontrer des requêtes inefficaces entraînant des problèmes tels que le redoutable problème n+1.

  3. Itérations de développement lentes  : de nombreux développeurs adaptent leurs API RESTful au flux de leurs applications. Cependant, à mesure que leurs applications se développent, des modifications importantes peuvent être nécessaires à la fois au front et au backend. Par conséquent, les API peuvent ne plus s'adapter à la forme des données de manière efficace ou percutante. Cela entraîne des itérations de produit plus lentes en raison de la nécessité de modifier l'API.

  4. Performances à grande échelle  : en raison de ces problèmes cumulatifs, l'évolutivité sera affectée dans de nombreux domaines. Les performances du côté des applications peuvent être affectées car vos demandes renverront trop ou trop peu de données (ce qui entraînera un plus grand nombre de demandes). Les deux situations sollicitent inutilement le réseau, ce qui entraîne de mauvaises performances. Du côté des développeurs, la vitesse de développement peut être réduite car vos API sont fixes et ne correspondent plus aux données qu'ils demandent.

L'argument de vente de GraphQL est de surmonter les inconvénients de REST. Voici quelques-unes des principales solutions proposées par GraphQL aux développeurs :

  1. Points de terminaison uniques  : GraphQL utilise un seul point de terminaison pour interroger les données. Il n'est pas nécessaire de créer plusieurs API pour s'adapter à la forme des données. Il en résulte une diminution du nombre de demandes transitant par le réseau.

  2. Récupération  : GraphQL résout les problèmes récurrents liés à la surestimation et à la sous-extraction en définissant simplement les données dont vous avez besoin. GraphQL vous permet de mettre en forme les données en fonction de vos besoins afin de ne recevoir que ce que vous avez demandé.

  3. Abstraction  : les API GraphQL contiennent quelques composants et systèmes qui décrivent les données à l'aide d'une norme indépendante du langage. En d'autres termes, la forme et la structure des données sont normalisées afin que le front et le backend sachent comment elles seront envoyées sur le réseau. Cela permet aux développeurs des deux côtés de travailler avec les systèmes de GraphQL et non pas avec eux.

  4. Itérations rapides  : en raison de la standardisation des données, les modifications d'un côté du développement peuvent ne pas être nécessaires de l'autre. Par exemple, les modifications de présentation du frontend peuvent ne pas entraîner de modifications importantes du backend car GraphQL permet de modifier facilement la spécification des données. Vous pouvez simplement définir ou modifier la forme des données pour répondre aux besoins de l'application au fur et à mesure de son évolution. Cela se traduit par une réduction des travaux de développement potentiels.

Ce ne sont là que quelques-uns des avantages de GraphQL. Dans les prochaines sections, vous découvrirez comment GraphQL est structuré et quelles sont les propriétés qui en font une alternative unique à REST.