tRPC vs GraphQL : typage de bout en bout pour vos API
Obtenez un résumé intelligent et des insights personnalisés
tRPC vs GraphQL répondent au même besoin. À savoir : sécuriser le typage entre le client et le serveur. Cependant, GraphQL s’appuie sur un schéma explicite. Il convient aux API publiques ou consommées par plusieurs types de clients. D’un autre côté, tRPC partage directement les types TypeScript entre le client et le serveur. Ici, il n’y a pas de schéma ni de génération de code. Le choix dépend surtout du nombre de clients à servir et du langage utilisé côté client.
La question est : que résous tRCP vs GraphQL ? Une API REST (Representational State Transfer) classique ne garantit rien à la compilation. En outre, un champ renommé côté serveur casse le client sans avertissement. L’erreur apparaît en production, pas avant. GraphQL vs tRPC apportent chacun une réponse à ce problème, avec des philosophies opposées. Alors, comparons les deux approches. D’un autre côté, vous pouvez aussi envisager une troisième voie : REST associé à Zod et OpenAPI. Chez AquilApp, nous choisissons cette architecture projet par projet. Tout dépend du nombre de clients et l’équipe en place.
GraphQL : le schema-first et écosystème mature
GraphQL est un langage de requête et un environnement d’exécution pour API (Application Programming Interface). Le client décrit précisément les données dont il a besoin. Ensuite, le serveur renvoie exactement cette structure.
Facebook a développé GraphQL en 2012 pour ses applications mobiles. La spécification est passé open source en 2015. Depuis 2018, elle est supervisée par la GraphQL Foundation, hébergée par la Linux Foundation.
Ce modèle repose sur un schéma qui définit les types de données disponibles et les opérations possibles. Des fonctions appelées resolvers exécutent chaque requête. Elles vont chercher la donnée, en base ou via d’autres services. Ce fonctionnement corrige deux défauts classiques du REST :
- Le sur-fetching (trop de données renvoyées)
- Et le sous-fetching (des données manquantes qui obligent à enchaîner plusieurs appels).
À savoir : l’écosystème GraphQL a dix ans d’existence. Apollo fournit un client et un serveur complets. Relay, développé par Meta, cible les applications React à grande échelle. Hasura génère une API GraphQL directement depuis une base de données.
Évidemment, cette maturité a un coût. Le typage TypeScript côté client nécessite un outil de génération de code. Tel est le cas de GraphQL Code Generator. En outre, le schéma doit être maintenu et versionné séparément du code métier. Une requête mal conçue peut aussi déclencher un grand nombre d’appels en base, le problème dit du N+1.
tRPC : le zero-schema, TypeScript natif
tRPC est une bibliothèque TypeScript. Il partage notamment les types entre client et serveur via le compilateur. Encore une fois, il n’y a pas de schéma ni génération de code. Le développeur définit des fonctions serveur, appelées procédures. De son côté, le client y accède avec un typage complet et automatique.
Alex « KATT » Johansson, développeur suédois, a créé tRPC en reprenant un prototype existant. L’outil s’est fait connaître dans l’écosystème du T3 Stack. En effet, c’est une combinaison Next.js, tRPC, Prisma et Tailwind CSS très utilisée pour démarrer une application TypeScript full-stack rapidement.
Le principe est simple :
- Pas de fichier .graphql,
- Pas d’étape de build pour générer les types,
- Pas de rpc (remote procedure call) au sens réseau classique.
Donc, une procédure ajoutée côté serveur est immédiatement visible et typée côté client, dans le même projet.
La version 11 de tRPC est sortie fin 2025. Elle ajoute la compatibilité avec les React Server Components et le streaming de réponses via des itérables. Cette version aligne tRPC avec le modèle App Router de Next.js.
Attention cependant, tRPC impose une contrainte forte. Notamment, le client et le serveur doivent être écrits en TypeScript, idéalement dans un même monorepo. Donc, un client mobile natif en Swift ou en Kotlin ne peut pas consommer une API tRPC directement. En plus, l’outil n’est pas non plus conçu pour une API publique. Il n’existe pas de schéma lisible par un développeur tiers.
Comparons le DX, la performance, le tooling et la courbe d’apprentissage de tRPC vs GraphQL
Le tableau suivant synthétise les écarts entre les deux approches.
| Critère | GraphQL | tRPC |
|---|---|---|
| Typage TypeScript | Via génération de code (codegen) | Natif, par le compilateur |
| Schéma | Obligatoire, fichier dédié | Aucun |
| Clients pris en charge | Tout langage (web, mobile, tiers) | TypeScript uniquement |
| Mise en place | Schéma + resolvers, plus longue | Fonctions TypeScript, minimale |
| Courbe d’apprentissage | Moyenne à élevée | Faible à moyenne |
| Écosystème | Mature, 10 ans (Apollo, Relay, Hasura) | Jeune, en forte croissance |
| Téléchargements npm/semaine | ~43,3 millions (paquet graphql) | ~4,3 millions (@trpc/server) |
| Étoiles GitHub | ~20 350 (dépôt de la spécification) | ~40 445 |
Sources : npmtrends.com (comparaison @trpc/client vs @trpc/server vs graphql, consultée en août 2026) ; graphql.org ; trpc.io.
Néanmoins, faites attention à ces chiffres. Le paquet graphql est une dépendance technique de nombreux frameworks (Apollo, Hasura, Relay). Son volume de téléchargements ne reflète pas un nombre d’applications finales comparable à celui de tRPC. Il est plus directement lié à son usage réel dans des projets TypeScript. Pour un projet full-stack en TypeScript, cette distinction pèse davantage que le volume brut de téléchargements.
Pourquoi pas choisir REST + Zod + OpenAPI pour votre app ?
REST reste le style d’API le plus répandu. Il utilise les méthodes HTTP (HyperText Transfer Protocol) standards et le format JSON (JavaScript Object Notation). Sa faiblesse historique est justement le typage. Donc : rien ne garantit qu’un endpoint REST renvoie la structure attendue par le client.
Zod comble cette faille. Créée par le développeur Colin Hacks, cette bibliothèque TypeScript permet de définir un schéma de validation unique. Ce qui sert à la fois à valider les données à l’exécution et à inférer automatiquement le type TypeScript correspondant, sans double déclaration.
En outre, la spécification OpenAPI a évolué dans le même sens. Depuis sa version 3.1, elle est compatible avec JSON Schema. Cette évolution réduit l’écart avec GraphQL sur la documentation et le typage. Des outils comme zod-openapi ou openapi-typescript génèrent automatiquement une documentation OpenAPI ou des types client à partir d’un schéma Zod, ou l’inverse.
Attention cependant, cette combinaison REST + Zod + OpenAPI ne remplace ni GraphQL ni tRPC. Elle permet de garder la simplicité et la compatibilité universelle de REST. En plus, elle réduit le risque d’erreur de typage, pour un coût de mise en place raisonnable.
Quelle techno pour quel projet entre tRPC vs GraphQL ?
Le choix dépend avant tout du profil des clients qui consomment l’API.
| Contexte projet | Recommandation |
|---|---|
| SaaS avec plusieurs clients (web, mobile, partenaires) | GraphQL : un schéma commun, des requêtes flexibles par client |
| Dashboard interne ou back-office, une seule équipe | tRPC : vitesse de développement, un seul dépôt TypeScript |
| Startup en Next.js avec Prisma | tRPC via le T3 Stack |
| Application mobile consommant une API tierce | REST + OpenAPI : compatibilité avec les générateurs de SDK multi-langages |
| API publique destinée à des partenaires externes | REST + OpenAPI, ou GraphQL si les besoins de requête varient fortement |
Une comparaison REST vs GraphQL côté mobile détaille ce dernier cas de figure, propre aux contraintes des clients natifs iOS et Android.
Peut-on combiner les deux ?
Rien n’oblige à choisir entre tRPC vs GraphQL pour tout un système. Une architecture combinée reste pragmatique dans de nombreux projets. Donc :
- API REST documentée avec OpenAPI pour les intégrations externes et les webhooks
- Une couche tRPC ou GraphQL pour le frontend interne
- Et éventuellement du gRPC pour les communications entre services internes.
Un autre schéma courant place GraphQL en couche BFF (Backend For Frontend). Cette couche agrège plusieurs sources REST ou gRPC. De plus, elle présente un graphe unique aux clients. Cette organisation garde chaque outil sur son terrain de force, sans dogmatisme technique. Elle s’appuie aussi sur un pipeline CI/CD capable de déployer indépendamment chaque couche de l’API.
FAQ sur tRPC vs GraphQL : Comparatif des architectures d'API moderne
* **tRPC :** Est idéal pour des architectures Full-stack monolithiques ou des monorepos synchronisés où le front-end et le back-end sont rédigés en TypeScript.
* **GraphQL :** Reste la référence incontournable dès lors que l’API doit être consommée par des clients tiers hétérogènes (applications mobiles natives Swift/Kotlin, partenaires externes, clients multi-langages) nécessitant un contrat d’interface formel et la capacité de requêter précisément le sous-ensemble de données désiré.
* **REST + OpenAPI / gRPC :** Souvent la solution la plus robuste et la plus simple à maintenir pour une application mobile native (iOS/Android), facilitant l’automatisation de la génération de SDKs typés et légers.
* **GraphQL :** Particulièrement pertinent si l’application mobile comporte de nombreux écrans aux besoins de données très granulaires et divergents, permettant d’optimiser le nombre d’appels réseau en une seule requête (*single round-trip*) sur des réseaux cellulaires instables.
* **Problème du N+1 Query :** Le risque principal de baisse de performance en GraphQL découle de l’exécution naïve des *resolvers* imbriqués, générant une cascade de requêtes en base de données.
* **Gains réseau :** En évitant le *sur-rapatriement* de données (*over-fetching*), GraphQL réduit la taille des charges utiles JSON transmises sur le réseau par rapport à une API REST standard.
Conclusion
tRPC vs GraphQL, ou REST typé ne sont pas des concurrents interchangeables. En effet, chacun cible un contexte précis :
- La diversité des clients pour GraphQL,
- La vitesse d’un projet TypeScript unifié pour tRPC
- La compatibilité universelle pour REST associé à Zod et OpenAPI.
Alors, comment choisir ? Tenez compte de votre équipe, de vos clients et de votre feuille de route technique. Nos architectes accompagnent ce choix dès le cadrage de votre projet sur mesure.
Discuter de votre architecture d’API avec AquilApp
