Pourquoi GraphQL n'est pas la solution miracle ?

Dans beaucoup de projets, on pense souvent à tord, que GraphQL est la solution magique pour récupérer des données agrégées d'un coup.

On espère que cet outil va solutionner les problématiques de récupération en cascade des données.

Détrompez-vous !

GraphQL n'est pas un outil qui va régler un problème de complexité, mais plutôt un outil qui va déployer des données que vous avez déjà organisé.

Le besoin

Quel est le besoin ? Que cherche t-on à faire ?

Avant d'entammer chaque sujet, il faut se poser ces questions. Cela parait évident pour bon nombre d'entre nous, ça ne l'est pas pour tout le monde.

Combien de fois, j'ai vu atterir des tickets dans mon backlog qui étaient du genre: il faut faire ça ... (le "ça" = mise en oeuvre technique d'un outil).

Et dans 90% des cas, un ticket de ce genre ne répondra pas à la problématique.

Et bien souvent, GraphQL arrive dans les projets de cette façon.

On se trouvera ce genre d'excuse:

On a besoin de récupérer X items via l'ID de Y et pour chacun de ces items on doit récupérer N attributs et les objets Z qui sont attachés.

Pas si vite !

Avant de planifier des triples saltos arrières, sauts périlleux avant et double axel latéral... Avez-vous organisé les données pour distribuer un tel graph ?

GraphQL distribue les données en arbre, mais l'organisation n'est pas magique.

Car, si derrière vous avez une base SQL, et que chaque récupération de scope passe par une requête dédiée, tout ce que vous allez faire c'est lancer 50 requêtes en série pour 1 call API.

Je dis BRAVO !!!

Vous venez de ne pas résoudre votre problème, vous n'avez fait que l'amplifier.

Si votre besoin c'est de récupérer toujours la même organisation de données pour un utilisateur, il faut penser la distribution de cette donnée autrement.

Je m'explique.

Tu croivais en la magie, José ?

Pour tout ceux qui pensent que brancher un GraphQL va organiser vos données pour vous depuis le frontend et optimiser votre trafic réseau, arrêtez de vous leurrer.

Vous faîtes bien une requête du frontend vers le backend, mais votre backend va en faire 50 sur votre base et vos API.

Je vais vous expliquer concrètement pourquoi ça ne se fait pas:

Est-ce que vous pensez vraiment, que Facebook quand il distribue votre feed qui contient les derniers posts de vos contacts, qui est donc, 100% dédié à VOTRE utilisation et qui est totalement différente pour chacun de vos contacts, se dit:

OK je vais récupérer chacune de ces valeurs maintenant, en requêtant la table X puis la table Y en croisant l'ID etc...

JAMAIS DE LA VIE !

Votre feed est pré-compute, à aucun moment ils ne font ça à la volée (vous imaginez les coûts de ressources ?).

La réalité

A chaque fois que quelqu'un poste, ils vérifient qui sont les contacts de cette personne, et reconstruisent le feed.

Désormais, pour chaque utilisateur, on est en mesure de récupérer un feed en un seul appel par compte (sans sub query ou cascading compute).

En gros, ça va marcher avec des workers, du message queue/pipeline kafka pour traiter le débit entrant.

C'est impossible de faire ça à la volée, sur demande, avec 50 queries par requête API, votre serveur va littéralement prendre feu en une seule journée.

Et pour faire ça, il n'y a pas de magie, soit vous utilisez du stockage JSONB avec une limite de plusieurs dizaines d'items par ligne de feed, soit vous passez par une base de document.

Et pendant le scroll, on ira récupérer la prochaine ligne de feed qui contient elle-même X items, ce qui donnera l'impression de fluidité.

Ca devrait plutôt ressembler à ça:

Construction de la donnée et structuration en base

Lecture de la donnée

Ce qui signifie que si vous n'avez pas fait le travail pour mettre en place cette structure dans le traitement de vos données, je vais être sévère:

Oubliez GraphQL, ce n'est pas fait pour vous.

Soit vous le prenez trop à la légère, soit vous n'avez pas compris à quoi il sert.

Et ça se voit très vite qu'une organisation GraphQL n'est pas adaptée.

Si vous repérez des resolvers en cascade, c'est souvent un indicateur que vous êtes en train de faire n'importe quoi. Je me dois d'être honnête et cru, ce n'est plus qu'une question de charge pour que ça pète (problème d'accès concurrents etc...).

Donc, avant de passer à GraphQL, demandez-vous si vous avez réellement besoin de cet outil.

Parfois, pour faire un trou, on prend juste une perçeuse et pas un marteau-piqueur.