Software Craftmanship

GraphQL vs REST !

Découvrez nos jobs
Vous ambitionnez de devenir Tech Lead ou de faire du conseil de haut-niveau ? Nous avons des challenges à votre hauteur !

Depuis que la spécification GraphQL a été « opensourcé » par Facebook en 2015, elle a rapidement gagné en popularité dans le développement d’applications web et mobiles. Pourquoi la popularité soudaine de cette nouvelle technologie et quels sont les avantages de GraphQL par rapport aux API REST traditionnelles ? Dans cet article, nous allons aborder les principes de conception de GraphQL, comparer les requêtes dans GraphQL avec les mêmes requêtes REST, et nous plonger dans les avantages et inconvénients de GraphQL.

ARCHITECTURE GRAPHQL :

Comme les API RESTful, les API GraphQL sont conçues pour traiter les requêtes HTTP et fournir des réponses à ces requêtes. Cependant, c’est là que s’arrêtent les similitudes.

Alors que les API REST sont construites sur la connexion entre une méthode de requête et un endpoint, les API GraphQL sont conçues pour utiliser un seul endpoint qui est toujours interrogé avec une requête POST, généralement à l’URL yourdomain.com/graphql.

Le corps de la requête doit respecter la spécification GraphQL, et l’API doit disposer d’une logique côté serveur pour traiter ces requêtes et fournir la réponse appropriée. Cela permet une expérience client plus fluide que les API RESTful, qui peuvent exiger du client qu’il fasse plusieurs demandes pour plusieurs données et qu’il manipule les données une fois qu’elles sont renvoyées.

La logique côté serveur consiste en des documents avec des capacités définies. Ces documents contiennent des exécutables et des définitions de types ou d’objets. Les définitions des systèmes de types, comme leur nom l’indique, définissent les types et les formats acceptés pour les requêtes et les résultats de chaque champ de données. Les Executables contiennent une liste d’opérations possibles (requête, mutation), un nom pour l’opération, des champs à interroger ou à écrire, et un ensemble de sélection qui définit exactement quelles données seront renvoyées par l’opération.

Les ensembles de sélection constituent la plus grande valeur ajoutée de GraphQL – ils permettent au client d’interroger un ensemble de données spécifique et de recevoir une réponse contenant exactement les informations demandées.

EXEMPLE D’UNE REQUÊTE GRAPHQL :

La requête suivante permet de récupérer un livre qui possède l’id 225 ainsi que les nom et prénom de l’auteur du livre :

GET /graphql?query={ books(id:225) { authors { firstName, lastName } title, yearPublished, length } 
{ 
  Query {                 //  operation type
  books (id:12) {         //  operation endpoint
     authors {            //  requested fields
        firstName
        lastName
     } 
     title
     yearPublished    
    }
  }
}

Avec une seule requête qui est analysée et traitée par la logique du serveur GraphQL, nous pouvons récupérer un objet ainsi que tout ou une partie des objets liés. En comparant cela à la structure de la même requête dans l’architecture REST, les avantages de GraphQL commencent à apparaître clairement. De plus il est possible de préciser les champs de l’objet que l’on souhaite récupérer : Par exemple pour afficher une liste des titres des livres triée par table de publication, il suffirait de récupérer les champs « title » et « yearPublished ».

Voyons le même exemple avec une requête REST.

EXEMPLE D’UNE REQUÊTE REST :

Pour avoir le même résultat avec une requête REST, il faut dans un premier temps faire une requête en passant l’id du livre en paramètre :

GET /books/225

Ce qui nous retourne par exemple le résultat suivant :

{ 
  “title” : “The ultimate book”,
  “authorID”: 956,
  “yearPublished” : 1995,
  “length”: 288,
  “genre”: “Science Fiction”
}

On voit immédiatement les inconvénients de REST par rapport à GraphQL :

GET /authors/956

Si on veut afficher une liste de 10 livres, il faudra donc effectuer 10 requêtes pour récupérer les données puis 10 nouvelles requêtes pour récupérer les auteurs. Il est bien sûr possible de mettre en place un mécanisme de cache coté client pour éviter ces requêtes, mais cela devient rapidement compliqué.

Pour résumer, GraphQL est plus performant que REST d’un point de vue front end : Moins de requêtes, des résultats plus légers et plus complets, moins de trafic réseau, un code plus simple et plus logique. Par contre la mise en oeuvre coté serveur peur s’avérer plus complexe et coûteuse en temps mais ce surcoût permettra d’avoir un code maintenable et performant.

Vous êtes convaincus ? Voilà quelques liens pour vous lancer :

N’hésitez pas à commenter cet article si vous avez déjà migré des projets vers GraphQL, votre retour d’expérience nous intéresse ! Dans un prochain article nous verrons comment mettre en oeuvre un serveur GraphQL avec Spring Boot.

1+