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:

{
  utilisateurs: (
    {
      nom: 'Anthony',
      copains: (...)
    }
  )
}

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 à /utilisateurs/, 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 des éléments de données différents, 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 ne 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:

{
  utilisateurs (nom: "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 tel que 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 pour 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.

{
  utilisateurs (nom: "Anthony") {
    copains {
      Nom
    }
  }
}

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, /utilisateurs et /des postes 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 blocs séparés.

Comment commencez-vous?

GraphQL a beaucoup de bibliothèques de serveurs pour différentes langues, 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é peut être généré automatiquement basé sur la structure, mais à la fin de la journée, le schéma n'est qu'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 } = exiger('graphql');


var schéma = buildSchema(»
  type Requête {
    bonjour: String
  }
»);


var racine = {
  Bonjour: () => {
    revenir 'Bonjour le monde!';
  },
};


graphql(schéma, '{ salut }', racine).puis((réponse) => {
  console.Journal(réponse);
});

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