Le développement d'applications web modernes repose sur une communication fluide entre le frontend et le backend. Pourtant, maintenir la cohérence des types de données entre ces deux mondes a toujours été un défi, source d'erreurs et de ralentissements. C'est précisément ce problème que tRPC vient résoudre, en proposant une approche radicalement simple et efficace pour créer des API entièrement typées, sans effort.
Qu'est-ce que tRPC, concrètement ?
tRPC signifie TypeScript Remote Procedure Call. Pour faire simple, tRPC vous permet d'appeler des fonctions sur votre serveur depuis votre client (navigateur, application mobile) comme si elles étaient des fonctions locales. Il n'y a plus de barrière visible entre le client et le serveur.
La véritable magie de tRPC réside dans son utilisation de l'inférence de types de TypeScript. Au lieu de générer des schémas ou des fichiers de déclaration de types à partager entre le front et le back (comme on le ferait avec GraphQL ou OpenAPI), tRPC partage directement les types eux-mêmes. Le client connaît automatiquement les routes disponibles sur le serveur, les arguments qu'elles attendent et le format des données qu'elles retournent.
En résumé, avec tRPC, votre API n'est plus une simple URL, mais un contrat de types partagé. Si vous modifiez une fonction côté backend, votre code frontend qui l'utilise affichera une erreur de compilation instantanément, avant même que vous n'ayez rafraîchi votre navigateur.
Pourquoi tRPC a-t-il été créé ? Les limites des approches traditionnelles
Pour bien comprendre la valeur de tRPC, il faut regarder les solutions qu'il vient bousculer.
- Les API REST sont la norme depuis des années, mais elles manquent cruellement de typage natif. Le développeur doit manuellement s'assurer que les données envoyées et reçues correspondent à ce que le backend attend, souvent à l'aide de bibliothèques comme Zod ou Joi, ce qui ajoute de la complexité. La documentation (via Swagger/OpenAPI) est souvent désynchronisée de l'implémentation réelle.
- GraphQL a résolu le problème du typage et du sur-envoi de données (over-fetching) en introduisant un schéma fort. Cependant, cette puissance a un coût : une courbe d'apprentissage plus raide, une configuration complexe et la nécessité de maintenir un écosystème d'outils (clients, génération de code) assez lourd.
tRPC a été conçu pour offrir le meilleur des deux mondes : la simplicité d'appel d'une API REST avec la sécurité de type de bout en bout de GraphQL, mais sans la complexité de ce dernier.
Les avantages concrets de tRPC pour vos projets
Adopter tRPC se traduit par des bénéfices immédiats, surtout pour les équipes qui travaillent déjà avec TypeScript.
- Sécurité de type de bout en bout (End-to-end typesafety) : C'est l'avantage numéro un. Fini les erreurs du type
cannot read property 'name' of undefinedparce que l'API a changé. Votre éditeur de code (comme VS Code) vous prévient en temps réel. - Expérience développeur (DX) exceptionnelle : L'autocomplétion sur votre client pour les routes de l'API est bluffante. Vous tapez
trpc., et toutes les procédures disponibles apparaissent, avec leurs arguments et leurs types de retour. - Pas de génération de code : Contrairement à GraphQL, vous n'avez pas besoin d'une étape de "build" pour générer les types côté client. Tout est inféré automatiquement par TypeScript, ce qui simplifie énormément le workflow.
- Légèreté et simplicité : tRPC n'a pas d'opinion sur la manière dont vous structurez votre code. Il s'intègre facilement à des serveurs existants comme Express, Fastify ou directement dans des frameworks comme Next.js ou SvelteKit.
- Refactoring sans crainte : Renommer une route ou modifier la structure d'un objet retourné devient un jeu d'enfant. TypeScript vous montrera exactement tous les endroits à corriger dans votre base de code.
Comment fonctionne tRPC ? Le duo client-serveur
Le fonctionnement de tRPC repose sur deux composants principaux qui communiquent entre eux.
Le backend : le routeur et les procédures
Côté serveur, vous définissez un "routeur" (router). Ce routeur est simplement une collection de "procédures" (procedures). Chaque procédure est une fonction asynchrone qui peut être de deux types principaux :
- Query : Pour récupérer des données (équivalent d'un
GETen REST). - Mutation : Pour créer, modifier ou supprimer des données (équivalent de
POST,PUT,DELETE).
Vous pouvez également utiliser des bibliothèques comme Zod pour valider les entrées de vos procédures, ajoutant une couche de sécurité supplémentaire.
Le frontend : le client et les appels typés
Côté client, vous configurez un "client" tRPC en lui indiquant l'URL de votre serveur. C'est tout. Ce client importe le type du routeur que vous avez défini sur le backend.
Grâce à cette simple importation de type, le client tRPC sait exactement comment communiquer avec le serveur. Les appels ressemblent à ceci :
const { data, isLoading } = trpc.post.getById.useQuery({ id: '123' });const { mutate } = trpc.post.create.useMutation();
Ici, post, getById et create sont des noms que vous avez définis dans votre routeur backend. L'autocomplétion vous guidera, et TypeScript s'assurera que vous passez bien un objet avec une propriété id de type string.
tRPC face à REST et GraphQL : le comparatif
Pour y voir plus clair, voici un tableau qui résume les principales différences entre ces trois approches.
| Critère | tRPC | GraphQL | REST |
|---|---|---|---|
| Sécurité de type | Excellente (de bout en bout, sans effort) | Excellente (via un schéma) | Nulle (dépend de la validation manuelle ou d'OpenAPI) |
| Simplicité / Courbe d'apprentissage | Très simple si vous connaissez TypeScript | Complexe (schéma, résolveurs, outils) | Simple (concepts HTTP connus) |
| Dépendance | Fortement lié à TypeScript | Agnostique du langage | Agnostique du langage |
| Cas d'usage idéal | Applications full-stack TypeScript (Monorepos, Next.js) | API publiques, applications mobiles, microservices | API publiques simples, services web standards |
| Autocomplétion (DX) | Automatique et parfaite | Très bonne avec les bons outils | Inexistante ou dépendante de plugins OpenAPI |
Mettre en place tRPC : les étapes clés
Implémenter tRPC dans un projet est un processus étonnamment simple.
- Installation des dépendances : Vous installez les paquets
@trpc/servercôté backend et@trpc/clientainsi que@trpc/react-query(ou équivalent pour d'autres frameworks) côté frontend. - Définition du routeur backend : Dans un fichier côté serveur, vous créez votre routeur principal en y ajoutant des procédures. C'est là que toute la logique de votre API résidera.
- Exposition de l'API : Vous utilisez un adaptateur (
adapter) pour brancher votre routeur tRPC à votre serveur HTTP (par exemple, un handler Next.js ou un middleware Express). - Configuration du client frontend : Dans votre application frontend, vous créez le client tRPC en lui fournissant l'URL de l'API. Vous l'enrobez ensuite dans un "Provider" pour le rendre accessible à tous vos composants.
- Appel des procédures : Vous pouvez maintenant utiliser les hooks fournis (
useQuery,useMutation) dans vos composants pour appeler les procédures backend et interagir avec vos données de manière entièrement typée.
Qui utilise tRPC ? Preuves d'adoption et de maturité
tRPC n'est plus un projet confidentiel. Il est soutenu par une communauté très active et a été adopté par de nombreuses entreprises, des startups agiles aux plus grandes organisations.
- Plus de 35 000 étoiles sur GitHub.
- Des centaines de milliers de téléchargements hebdomadaires sur npm.
- Adopté par des entreprises comme Pleo, Vercel (dans certains projets) et Chakra UI.
- Au cœur de la populaire T3 Stack (Next.js, TypeScript, Tailwind CSS, tRPC, Prisma).
Ces chiffres ne sont pas juste des indicateurs de popularité ; ils témoignent de la robustesse et de la fiabilité de la technologie pour des projets en production.
Les limites et quand ne pas utiliser tRPC
Aucune technologie n'est parfaite. tRPC a aussi ses inconvénients et n'est pas adapté à tous les scénarios.
- Couplage fort avec TypeScript : Son plus grand atout est aussi sa principale contrainte. Si votre backend n'est pas en TypeScript ou si vous devez exposer votre API à des clients non-TypeScript, tRPC n'est pas le bon choix.
- Pas idéal pour les API publiques : tRPC est conçu pour une communication interne entre un front et un back que vous contrôlez. Pour une API publique destinée à des développeurs tiers, REST avec une spécification OpenAPI ou GraphQL reste une solution plus standard et interopérable.
- Mise en cache : La mise en cache HTTP, simple avec REST grâce aux verbes et aux URL, est moins directe avec tRPC. Le cache se gère principalement côté client via des bibliothèques comme React Query.
L'avenir de tRPC : vers quoi se dirige la technologie ?
tRPC continue d'évoluer rapidement. Son développement se concentre sur l'amélioration des performances, l'intégration avec les nouvelles fonctionnalités des frameworks (comme les React Server Components) et l'élargissement de son écosystème d'adaptateurs.
Il s'impose de plus en plus comme la solution de facto pour les développeurs qui cherchent à construire des applications full-stack TypeScript de manière rapide et robuste. Son approche pragmatique, qui privilégie la simplicité et l'expérience développeur, est une réponse directe aux complexités superflues que l'on trouve parfois dans l'ingénierie logicielle moderne.
En conclusion, tRPC n'est pas un remplaçant universel pour REST ou GraphQL, mais il représente une évolution majeure pour un cas d'usage très courant : les applications web et mobiles où le client et le serveur sont développés par la même équipe, sous le même parapluie technologique qu'est TypeScript. Dans ce contexte, il ne se contente pas d'améliorer le workflow ; il le transforme.
