masklinn a écrit :
Diminuer le couplage et la dépendance du front sur le back, en évitant les patterns d'accès vraiment pessimaux et en limitant la perte de bande passante.
T'as des équipes front qui font des essais principalement en lecture en permanence, qui vont pas nécessairement voire le jour, tu veux pas qu'ils soient en permanence bloqués par le back. Avec GQL, le back peut gérer l'expositions et les permissions de manière relativement grossière (surtout si ton modèle de permission est pas trop fin) et une fois qu'un objet est exposé n'importe qui peut l'utiliser dans le front, et avec un système de recherche global auto-publié une équipe front sans rapport peut le trouver s'ils en ont besoin, et aller l'utiliser sans faire chier personne.
Avec la recherche en profondeur ça évite les access patterns complètement dégénérés genre n+1 ou accéder aux objets un par un, ça facilite aussi le développement du front (moins de soupe de promesses / callbacks, surtout que ça prédate async/await), et t'as des équipes dédiés qui surveillent et peuvent prendre en main une query qui pose problème avec un handler custom.
Si en plus tu branches ça directement dans ton framework d'UI, les fronteux vont pas aller sélectionner le monde, ça va automatiquement sélectionner uniquement ce qui est utilisé, et tout bien rafraichir.
L'optimisation sur la lecture est très visible sur le fait que les mutations sont pas fondamentalement mieux que le RPC classique… mais vont embarquer une query à l'intérieur donc quand tu fais ton appel tu peux direct rafraichir ce qui t'intéresse via la réponse. Pendant ce temps le caching réseau tu t'en fous si tu pars du principe que les données sont super volatiles et que tu vas jamais fetcher 2x la même chose, tu veux surtout limité la quantité par fetch, et pouvoir pointer juste ce que tu veux pour maj ton client.
Avec des trucs plus classiques (que ce soit du RPC "classique" ou du pas-REST), les endpoints ont une réutilisabilité limitée sauf s'ils sont tout petits (ou vraiment énormes), donc soit t'augmentes le couplage (chaque changement de front touche le back) soit t'augmentes énormément ta conso réseau avec des millions de micro-requêtes ou des documents kilométriques qui partent directement à la poubelle. Mais le couplage front/back c'est pas gênant quand ce sont les mêmes gens, ou au moins des gens qui bossent ensemble / pas loin.
Après c'est moins utile si tu sais streamer tes maj en live via des souscriptions et un socket, genre.
C'est plus l'inverse en fait.
|