GraphQL n’a jamais eu tort. REST n’a jamais été obsolète. tRPC n’est pas non plus la réponse finale. Chacun résout un problème de coordination différent, et le bon choix dépend davantage des limites de l’équipe et des consommateurs que des préférences stylistiques.
Ce que chaque approche optimise
REST est puissant lorsque la compatibilité et les sémantiques HTTP sont importantes. Il fonctionne bien pour les API publiques, les consommateurs tiers et les systèmes où le contrat de transport doit rester indépendant du langage.
GraphQL est puissant lorsque de nombreux clients ont besoin de lectures flexibles contre un schéma partagé. Il centralise le contrat et donne aux clients le contrôle sur la forme, ce qui est précieux lorsque les besoins des interfaces sont variés.
tRPC est le plus fort lorsque une équipe TypeScript détient les deux extrémités et souhaite une itération rapide et sécurisée par type :
export const appRouter = router({
getUser: publicProcedure
.input(z.object({ id: z.string() }))
.query(({ input }) => db.user.findUnique({ where: { id: input.id } })),
});
C'est puissant, mais cela suppose un modèle de couplage assez étroit.
Le véritable compromis
Chaque style déplace la complexité ailleurs :
- REST pousse davantage la composition des formes aux clients
- GraphQL ajoute la gouvernance des schémas et la discipline des résolveurs
- tRPC vous lie plus étroitement à TypeScript et aux frontières de propriété internes
C'est pourquoi le style d’API n’est pas une idéologie. C'est une décision de conception organisationnelle.
Meilleure règle
Choisissez en fonction des consommateurs :
- public, large, indépendant du langage : REST
- de nombreuses formes de clients, un schéma central : GraphQL
- seule frontière organisationnelle TypeScript, itération interne rapide : tRPC
Le mauvais choix est d'utiliser un seul style partout juste pour avoir l'air cohérent.
Lectures complémentaires