pas idéal ! / Blogs / Perficient

Vous trouverez de nombreux articles sur l’incroyable qualité de GraphQL (y compris le mien), mais après un certain temps d’utilisation, j’ai quelques considérations concernant la technologie et je souhaite partager quelques réflexions amères à ce sujet.

Histoire de GraphQL

Comment tout cela a-t-il commencé? La meilleure façon de répondre à cette question est de revenir au problème initial de Facebook confronté.

En 2012, nous avons lancé un effort pour reconstruire les applications mobiles natives de Facebook. À l’époque, nos applications iOS et Android n’étaient qu’une mince enveloppe autour des vues de notre site Web mobile. Bien que cela nous ait rapproché d’un idéal platonique de l’application mobile « écrire une fois, exécuter n’importe où », en pratique, cela a poussé nos applications mobiles d’affichage Web au-delà de leurs limites. À mesure que les applications mobiles de Facebook devenaient plus complexes, elles subissaient de mauvaises performances et tombaient fréquemment en panne. Lors de la transition vers des modèles et des vues implémentés de manière native, nous avons eu pour la première fois besoin d’une version de données API du fil d’actualité, qui jusque-là n’était fournie qu’au format HTML.

Nous avons évalué nos options pour fournir des données de fil d’actualité à nos applications mobiles, y compris les ressources du serveur RESTful et les tables FQL (l’API de type SQL de Facebook). Nous étions frustrés par les différences entre les données que nous souhaitions utiliser dans nos applications et les requêtes serveur qu’elles nécessitaient. Nous ne pensons pas aux données en termes d’URL de ressources, de clés secondaires ou de tables de jointure ; nous y pensons en termes de graphe d’objets.

Facebook a rencontré un problème spécifique et a créé sa propre solution : GraphQL. Pour représenter les données sous forme de graphique, l’entreprise a conçu un langage de requête hiérarchique. En d’autres termes, GraphQL suit naturellement les relations entre les objets. Vous pouvez désormais recevoir des objets imbriqués et les renvoyer tous dans une seule requête HTTPS. À l’époque, il était crucial pour les utilisateurs du monde entier de ne pas toujours disposer de forfaits mobiles bon marché/illimités. Le protocole GraphQL a donc été optimisé, permettant uniquement de transmettre ce dont les utilisateurs avaient besoin.

Par conséquent, GraphQL résout les problèmes de Facebook. Est-ce que cela résout le vôtre ?

Tout d’abord, récapitulons les avantages

• Demande unique, ressources multiples: Par rapport à REST, qui nécessite plusieurs requêtes réseau à chaque point de terminaison, avec GraphQL vous pouvez demander toutes les ressources avec un seul appel.
• Recevez des données précises: GraphQL minimise la quantité de données transférées via les câbles, en les sélectionnant de manière sélective en fonction des besoins de l’application client. Ainsi, un client mobile doté d’un petit écran peut recevoir moins d’informations.
• Frappe forte: Chaque objet de requête, d’entrée et de réponse a un type. Dans les navigateurs Web, le manque de types en JavaScript est devenu une faiblesse que divers outils (Dart de Google et TypeScript de Microsoft) essayez de compenser. GraphQL vous permet d’échanger des types entre le backend et le frontend.
• Meilleurs outils et convivialité pour les développeurs: Le serveur introspectif peut être interrogé sur les types qu’il prend en charge, permettant ainsi les avertissements de l’explorateur d’API, de la saisie semi-automatique et de l’éditeur. Ne comptez plus sur les développeurs backend pour documenter leurs API. Explorez simplement les points de terminaison et obtenez les données dont vous avez besoin.
• Indépendant de la version: le type de données renvoyées est déterminé uniquement par la demande du client, les serveurs deviennent donc plus simples. Lorsque de nouvelles fonctionnalités côté serveur sont ajoutées au produit, de nouveaux champs peuvent être ajoutés sans affecter les clients existants.

Grâce au principe « requête unique, ressources multiples », le code front-end est devenu beaucoup plus simple avec GraphQL. Imaginez une situation dans laquelle un utilisateur souhaite obtenir des détails sur un écrivain spécifique, par exemple (nom, pièce d’identité, livres, etc.). Dans un modèle REST intuitif traditionnel, cela nécessiterait de nombreuses requêtes croisées entre les deux points de terminaison /writers et /books, que le frontend devrait ensuite fusionner. Cependant, grâce à GraphQL, nous pouvons définir toutes les données nécessaires dans la requête, comme indiqué ci-dessous :

writers(id: "1") {
  id
  name
  avatarUrl
  books(limit: 2) {
    name
    urlSlug
  }
}

Le principal avantage de ce modèle est de simplifier le client code. Cependant, certains développeurs espéraient l’utiliser pour optimiser les appels réseau et accélérer le démarrage des applications. Vous ne rendez pas le code plus rapide; tu as simplement transférer la complexité vers le backend, qui a plus de puissance de calcul. De plus, pour de nombreux scénarios, les métriques montrent que l’utilisation de l’API REST semble plus rapide que celle de GraphQL.

Ceci concerne principalement les applications mobiles. Si vous travaillez avec une application de bureau ou une API machine à machine, il n’y a aucune valeur ajoutée en termes de performances.

Un autre point est que vous pouvez effectivement économiser quelques kilo-octets avec GraphQL, mais si vous vraiment Si vous souhaitez optimiser les temps de chargement, il vaut mieux se concentrer sur le chargement d’images de moindre qualité pour mobile, comme nous le verrons, GraphQL ne fonctionne pas très bien avec les documents.

Mais voyons ce qui ne va pas ou ce qui pourrait être mieux avec GraphQL.

Fortement tapant

GraphQL définit tous les types d’API, commandes et requêtes dans le graphql.schema déposer. Cependant, j’ai trouvé que taper avec GraphQL peut prêter à confusion. Tout d’abord, il y a ici beaucoup de duplications. GraphQL définit le type dans le schéma, mais nous devons remplacer les types pour notre backend (TypeScript avec node.js). Vous devez déployer des efforts supplémentaires pour que tout fonctionne avec Zod ou créer une génération de code fastidieuse pour les types.

Débogage

Il est difficile de trouver ce que vous recherchez dans l’inspecteur Chrome, car tous les points de terminaison se ressemblent. Dans REST, vous pouvez savoir quelles données vous obtenez simplement en regardant l’URL :

Voyez-vous la différence?

Aucune prise en charge des codes d’état

REST vous permet d’utiliser des codes d’erreur HTTP tels que « 404 introuvable », « 500 erreur de serveur », etc., mais pas GraphQL. GraphQL force le retour d’un code d’erreur 200 dans la charge utile de la réponse. Pour comprendre quel point de terminaison a échoué, vous devez vérifier chaque charge utile. Il en va de même pour la surveillance : la surveillance des erreurs HTTP est très simple par rapport à GraphQL car elles ont toutes leur propre code d’erreur, tandis que le dépannage de GraphQL nécessite l’analyse des objets JSON.

De plus, certains objets peuvent être vides, soit parce qu’ils sont introuvables, soit parce qu’une erreur s’est produite. Il peut être difficile de faire la différence d’un seul coup d’œil.

Gestion des versions

Tout a son prix. Lors de la modification de l’API GraphQL, vous pouvez rendre certains champs obsolètes, mais vous êtes obligé de maintenir une compatibilité ascendante. Ils devraient quand même rester là pour les clients plus âgés qui les utilisent. Vous n’avez pas besoin de prendre en charge le versioning GraphQL, au prix de la maintenance de chaque champ.

Pour être honnête, la gestion des versions REST est également un problème, mais elle fournit une fonctionnalité intéressante pour les fonctionnalités expirantes. Dans REST, tout est un point de terminaison, vous pouvez donc facilement bloquer les anciens points de terminaison pour un nouvel utilisateur et mesurer qui utilise toujours l’ancien point de terminaison. Les redirections pourraient également simplifier la gestion des versions des plus anciennes aux plus récentes dans certains cas.

Pagination

Les meilleures pratiques GraphQL suggèrent ce qui suit :

La spécification GraphQL reste délibérément silencieuse sur plusieurs problèmes importants liés à l’API, tels que la mise en réseau, l’autorisation et la pagination.

Comme c’est pratique » (pas!). En général, il s’avère que la pagination dans GraphQL est très pénible.

Mise en cache

L’intérêt de la mise en cache est de recevoir une réponse du serveur plus rapidement en stockant les résultats des calculs précédents. Dans REST, les URL sont des identifiants uniques des ressources auxquelles les utilisateurs tentent d’accéder. Par conséquent, vous pouvez effectuer une mise en cache au niveau des ressources. La mise en cache fait partie de la spécification HTTP. De plus, le navigateur et l’appareil mobile peuvent également utiliser cette URL et mettre en cache les ressources localement (comme ils le font avec les images et CSS).

Dans GraphQL, cela devient délicat car chaque requête peut être différente même si elle travaille sur la même entité. Cela nécessite une mise en cache au niveau du champ, ce qui n’est pas facile à réaliser avec GraphQL car il utilise un seul point de terminaison. Des bibliothèques comme Prisma et Dataloader ont été développées pour faciliter de tels scénarios, mais elles ne disposent toujours pas des capacités REST.

Types de médias

GraphQL ne prend pas en charge le téléchargement de documents sur le serveur, qui est utilisé multipart-form-data par défaut. Les développeurs d’Apollo ont travaillé sur une solution de téléchargement de fichiers, mais elle est difficile à mettre en place. De plus, GraphQL ne prend pas en charge un en-tête de types de média lors de la récupération d’un document, ce qui permet au navigateur d’afficher correctement le fichier.

J’ai déjà publié un article sur les étapes à suivre pour télécharger une image sur Sitecore Media Library (soit XM Cloud, soit XM 10.3 ou version ultérieure) par en utilisant l’API de création GraphQL.

Sécurité

Lorsque vous travaillez avec GraphQL, vous pouvez interroger exactement ce dont vous avez besoin, mais vous devez être conscient que cela a des implications de sécurité complexes. Si un attaquant tente d’envoyer une requête coûteuse avec des pièces jointes pour surcharger le serveur, il peut alors le considérer comme une attaque DDoS.

Ils pourront également accéder à des champs qui ne sont pas destinés à l’accès du public. Lorsque vous utilisez REST, vous pouvez contrôler les autorisations au niveau de l’URL. Pour GraphQL, cela devrait être le niveau du champ :

user {
  username <-- anyone can see that
  email <-- private field
  post {
    title <-- some of the posts are private
  }
}

Conclusion

REST est devenu le nouveau SOAP ; désormais GraphQL est le nouveau REST. L’histoire se répète. Il est difficile de dire si GraphQL sera simplement une nouvelle tendance populaire qui sera progressivement oubliée, ou s’il changera véritablement les règles du jeu. Une chose est sûre : il nécessite encore un peu de développement pour obtenir plus de maturité.