Quand choisiriez-vous GraphQL plutôt que REST pour un nouveau service ?

Prenez GraphQL quand plusieurs clients différents ont besoin de formes différentes des mêmes données connectées et que vous en avez assez de surcharger les réponses ou de livrer un endpoint par écran. Prenez REST quand la surface est petite, que le cache HTTP compte, ou que les consommateurs sont des machines plutôt que des écrans. GraphQL ne supprime pas la complexité ; il la déplace de la prolifération d'endpoints vers la profondeur des resolvers, les limites de coût des requêtes, et un cache dont vous êtes désormais responsable.

Mon facteur décisif, c'est la diversité des clients. S'il y a un seul client web et que les endpoints correspondent proprement aux écrans, REST demande moins de machinerie et vous avez le cache HTTP, le comportement CDN et le débogage avec curl gratuitement. Dès que vous avez une application web, une application mobile et une intégration partenaire qui veulent chacune des tranches différentes du même graphe, REST se transforme soit en cinquante endpoints sur mesure, soit en réponses obèses que les utilisateurs mobiles paient en données. C'est là que GraphQL est rentable. Ce dont je m'assure que l'équipe est prévenue, c'est de ce qui vient avec. Il vous faut des limites de profondeur et de coût des requêtes ou une seule requête imbriquée peut marteler la base, il vous faut du batching à la dataloader ou les resolvers produisent des N plus une requêtes par défaut, et le cache HTTP cesse à peu près de fonctionner puisque tout est un POST vers une seule URL, donc vous mettez en cache au niveau du resolver ou de l'entité. Sur un produit de taille moyenne, je démarrerais honnêtement en REST et n'ajouterais GraphQL que quand un deuxième client très différent apparaît.