GraphQL

GraphQL a été conçu pour répondre aux faiblesses typiques des interfaces REST classiques. Au centre se trouve un schéma fortement typé, qui décrit tous les types de données, champs et relations disponibles. Ce schéma constitue le contrat entre client et serveur et sert en même temps de documentation.

Une requête GraphQL est déclarative : le client formule une requête qui ressemble à la structure de réponse souhaitée, et le serveur la remplit de données. Il existe au fond trois types d'opérations : query pour lire, mutation pour modifier et subscription pour des mises à jour en temps réel via des connexions permanentes.

La plus grande différence tient à la sélection des données. Avec REST, chaque point d'entrée livre une structure fixe, ce qui mène souvent à de l'over-fetching (trop de données) ou de l'under-fetching (trop peu, plusieurs requêtes nécessaires). GraphQL contourne les deux, le client demandant exactement les champs voulus et réunissant des données imbriquées en une seule requête.

REST marque en revanche des points par sa simplicité, un cache HTTP éprouvé et un large soutien des outils. Comme GraphQL n'utilise le plus souvent qu'un seul point d'entrée, le cache HTTP classique est plus difficile et exige des stratégies propres côté client ou serveur.

Le choix dépend du cas d'usage : GraphQL brille sur des besoins de données complexes et variés, tandis que REST reste souvent la solution la plus pragmatique pour des ressources simples et bien délimitées. Beaucoup d'organisations emploient les deux approches en parallèle et décident, interface par interface, quel style convient le mieux au flux de données et aux clients concernés.

Parmi ses forces figurent le contrôle précis des données, la réduction du nombre de requêtes et le typage fort, qui rend possibles des outils d'autocomplétion, de validation et de documentation. Les équipes frontend peuvent souvent répondre à de nouveaux besoins de données sans modifier le backend, tant que les champs existent dans le schéma.

En face se trouvent des défis. Des requêtes complexes ou profondément imbriquées peuvent fortement charger le serveur, d'où la nécessité de mécanismes de protection comme la limitation de profondeur et l'analyse de complexité. La mise en cache et la supervision sont aussi plus exigeantes qu'avec REST, les requêtes ne se distinguant pas par l'URL.

Un piège particulier est le fameux problème N+1 lors de la résolution de champs imbriqués, qui se désamorce toutefois avec des techniques comme le batching.

GraphQL convient particulièrement aux applications à nombreux clients différents, par exemple web et applications mobiles, qui ont chacun besoin d'extraits de données distincts. Via un schéma commun, tous s'adressent au même point d'entrée, sans qu'il faille entretenir des points d'entrée propres à chaque client.

Un motif d'architecture répandu est le schema stitching ou la fédération, où plusieurs services GraphQL sont réunis en un schéma commun. Les équipes peuvent ainsi exploiter leurs domaines de façon indépendante, tandis que les clients obtiennent malgré tout un point d'entrée unique et cohérent.

Au centre se trouve la définition du schéma dans le schema definition language. Y sont décrits les types d'objets avec leurs champs, les types d'entrée query et mutation ainsi que les types scalaires et composés. Le schéma est le contrat contraignant sur lequel serveur et clients s'alignent également.

À chaque champ est associé côté serveur un resolver, soit une fonction qui fournit la valeur du champ. Les resolvers peuvent tirer leurs données de bases de données, d'autres services ou d'interfaces REST existantes. Une couche GraphQL peut ainsi se poser aussi sur des paysages de systèmes anciens, sans les reconstruire entièrement.

Pour les clients existent des bibliothèques abouties, qui formulent les requêtes de façon typée, mettent les résultats en cache et optimisent le chargement de données imbriquées. L'effort côté frontend se réduit ainsi considérablement, et le typage fort évite beaucoup d'erreurs dès le développement.