Qu’est-ce que GraphQL et en quoi est-il différent de REST?

GraphQL est un langage de requête et un résolveur d’exécution pour les API, utilisé pour apporter plus de structure aux services qui fonctionnent avec des données complexes. Avec GraphQL, les clients peuvent demander uniquement les données dont ils ont besoin, et rien de plus.

La différence est de savoir qui définit le schéma

Les API REST traditionnelles impliquent un serveur d’API qui répond aux demandes avec des données structurées, généralement sous la forme de JSON. Si vous faites une demande GET à api.com/users/, vous pourriez vous attendre à recevoir en réponse quelque chose du genre:

{
  users: [
    {
      name: 'Anthony',
      friends: [...]
    }
  ]
}

Votre application aura une apparence différente, mais le fait est que le schéma est défini par le point de terminaison REST. Vous avez seulement fait une demande à /users/, mais vous avez récupéré toutes ces données.

Cela fonctionne bien, cependant, si vous savez quelles données vous allez récupérer, et c’est la norme pour la majorité des services sur le Web. Cependant, si vous effectuez des requêtes PUT, vous devez fournir à l’API les paramètres appropriés pour qu’elle fonctionne, sinon vous rencontrerez des erreurs. Bien sûr, vous pouvez utiliser des paramètres d’URL pour transmettre des valeurs à l’API, telles que l’ID utilisateur à récupérer, que vous pouvez utiliser pour rendre l’API plus dynamique.

Les API GraphQL font les choses un peu différemment. Plutôt que de faire des demandes individuelles à différents points de terminaison, qui représentent tous différents éléments de données, une application GraphQL enverra une demande à une seule origine. Le corps de la requête contient un schéma et indique à l’API les données à renvoyer. De cette façon, vous pouvez demander des données complexes en une seule demande et l’API n’en renvoie jamais plus que ce qui lui est demandé, réduisant ainsi les tailles de réponse importantes.

Par exemple, si vous souhaitez demander l’adresse e-mail d’un utilisateur spécifique, vous pouvez envoyer une requête GraphQL au api.com endpoint, avec la requête suivante:

{
  users(name: "Anthony") {
    email
  }
}

Peu importe si l’objet «Utilisateur» contient des champs pour d’autres informations; comme vous n’avez demandé que l’e-mail, vous ne recevrez que l’e-mail. Bien sûr, vous recevez toujours un objet JSON comme REST, et vous communiquez toujours de la même manière, mais les demandes sont beaucoup plus informatives.

Pour les applications avec un schéma complexe, ce type d’API peut être très utile pour des raisons d’organisation. Avec GraphQL, vous êtes obligé de définir strictement votre schéma lors de la configuration de l’API, tout comme le typage statique vous oblige à adhérer aux structures et aux types. La structure des données est facilement référençable et modifiable. Vous pouvez facilement obtenir ce même effet avec les API REST standard, mais GraphQL l’applique.

De plus, les requêtes GraphQL peuvent être plus efficaces. Par exemple, la requête «amis d’amis» est un problème courant. Dans une API REST, vous devez envoyer une demande à l’utilisateur en question, puis après avoir reçu les identifiants de ses amis, vous envoyez des demandes individuelles pour les informations de chaque ami, puis filtrez tout cela pour ce que vous voulez. Bien sûr, vous pouvez (et devriez) implémenter un nouveau point de terminaison pour effectuer cette requête du côté de la base de données, mais c’est un bandaid sur le vrai problème.

Avec GraphQL, cette requête est simple. Il vous suffit de spécifier que vous voulez le nom de chaque ami, et (en supposant que le backend est configuré pour gérer cela correctement) l’API gérera cette interaction naturellement, sans configuration spéciale pour chaque requête.

{
  users(name: "Anthony") {
    friends {
      name
    }
  }
}

Bien sûr, GraphQL n’est pas sans inconvénients. Pour les applications simples, il est beaucoup trop complexe de remplacer un point de terminaison REST de base. De plus, avec une API REST traditionnelle, vous bénéficiez de la possibilité de fractionner différentes routes. Par exemple, /users et /posts peuvent être gérés par des fonctions Lambda sans serveur distinctes, et peuvent être travaillés et mis à jour indépendamment les uns des autres, un concept connu sous le nom de backend de microservices. Pour GraphQL, il est beaucoup plus centralisé et plus difficile (mais pas impossible) de se diviser en morceaux séparés.

Comment commencez-vous?

GraphQL dispose de nombreuses bibliothèques de serveurs pour différents langages, mais il est couramment utilisé avec JavaScript et NodeJS.

Une requête GraphQL a besoin de deux choses: un schéma, qui définit la structure et les types des données, et un résolveur, qui prend une entrée et renvoie la valeur associée au schéma. Dans le résolveur, vous pouvez effectuer des opérations telles que récupérer des requêtes de base de données, modifier des données et effectuer toutes les actions dont vous avez besoin, à condition que tout se condense en une valeur de retour correspondant au schéma à la fin.

Pour les applications complexes, le schéma et le résolveur associé peuvent être générés automatiquement en fonction de la structure, mais à la fin de la journée, le schéma est juste une définition de type et le résolveur est juste un objet avec des fonctions qui résout différentes clés dans le schéma .

var { graphql, buildSchema } = require('graphql');


var schema = buildSchema(`
  type Query {
    hello: String
  }
`);


var root = {
  hello: () => {
    return 'Hello world!';
  },
};


graphql(schema, '{ hello }', root).then((response) => {
  console.log(response);
});

Pour plus d’informations sur la configuration d’un serveur GraphQL complet, vous pouvez lire le guide de GraphQL sur son installation et son utilisation avec Express.