tRPC vs GraphQL Comparaison

Zéro codegen, sécurité de type TypeScript de bout en bout

VS
GraphQL

Langage de requête universel, schema-first, pour clients multiples

16 min de lectureBackend

Verdict rapide

Décidez selon votre contexte : la seule « sécurité de type » n'est pas un argument suffisant pour GraphQL. Si vous utilisez un seul monorepo TypeScript avec un seul client web, tRPC demande presque toujours moins de travail — zéro codegen, et un changement côté serveur devient immédiatement une erreur TS côté client. Si vous avez une application mobile, une API publique ouverte aux développeurs externes ou un besoin de fédération multi-équipes, le contrat de schéma indépendant du langage de GraphQL et l'écosystème Apollo Federation offrent un avantage structurel.

tRPCGraphQL
Lire le verdict complet

Comparaison des scores

Chargement du graphique...

Notation détaillée

Notation détaillée: tRPC et GraphQL — notes sur 10, catégorie par catégorie
CatégorietRPCGraphQL
Performance
7/10
6/10
Facilité d'apprentissage
8/10
5/10
Écosystème
6/10
9/10
Communauté
7/10
8/10
Marché de l'emploi
5/10
8/10
Pérennité
7/10
8/10

Avantages & Inconvénients

tRPC

Avantages

  • Aucune génération de code ni étape de build — les types du serveur circulent directement vers le client
  • Lorsque vous modifiez le serveur, le client affiche l'erreur TypeScript avant même d'enregistrer le fichier
  • Des adaptateurs officiels existent pour React, Next.js, Express, Fastify, AWS Lambda, Solid et Svelte
  • Intégration native avec TanStack Query — les factories queryKey/queryOptions sont fournies prêtes à l'emploi
  • Des entreprises comme Netflix et Pleo l'utilisent en production, selon la FAQ officielle
  • Même la dépendance à TanStack Query est optionnelle — un simple client vanilla suffit
  • Les subscriptions sont prises en charge via WebSocket ou SSE ; la configuration SSE est recommandée comme plus simple
  • Sous licence MIT, entièrement open source — aucune offre entreprise payante

Inconvénients

  • Le partage de types dépend du même monorepo TypeScript — un client mobile natif perd cet avantage
  • Aucune surface API publique/REST officielle ; un package tiers comme `trpc-to-openapi` est nécessaire
  • Pas d'introspection de schéma — n'offre pas de contrat auto-documenté aux développeurs externes
  • Pas de sélection de champs — chaque procédure a un type de retour fixe
  • Inutilisable lorsque le backend est écrit dans un langage autre que JavaScript/TypeScript
  • Aucune norme officielle de fédération/composition de schéma multi-services

Idéal pour

Produits avec un seul monorepo TypeScript et un seul client webProjets full-stack TS basés sur Next.js, Express ou FastifyÉquipes de petite à moyenne taille recherchant une itération rapideOutils internes et panneaux d'administration sans consommateur externeProjets utilisant déjà TanStack Query

GraphQL

Avantages

  • Le client sélectionne uniquement les champs dont il a besoin — l'over/under-fetching est résolu structurellement
  • Contrat de schéma indépendant du langage — sert nativement chaque client : iOS, Android, web et tiers
  • S'auto-documente via l'introspection ; explorable avec des outils comme GraphiQL
  • Permet l'évolution du schéma sans changement cassant grâce au mécanisme de dépréciation
  • Le problème N+1 est résolu par batching et caching grâce au package officiel `graphql/dataloader`
  • Apollo Federation offre un support officiel de composition pour les architectures multi-équipes/multi-services
  • Géré depuis 2018 par la GraphQL Foundation, sous l'égide de la Linux Foundation
  • Des clients officiels comme Relay évitent les rendus inutiles grâce à un cache normalisé

Inconvénients

  • Pas de structure d'URL compatible avec le cache HTTP — nécessite un ID global et un cache client normalisé
  • La conception de schéma, l'architecture des resolvers et des concepts comme le dataloader alourdissent la courbe d'apprentissage
  • La fédération est encore en cours de standardisation — le Composite Schema Working Group est activement en travaux
  • À l'échelle entreprise, des couches comme Apollo GraphOS sont payantes (plan Developer : 5 $/million de requêtes)
  • Laisser le risque N+1 sans dataloader est une classe d'erreur fréquemment rencontrée
  • Pour des scénarios CRUD simples, nécessite plus de boilerplate (schéma + resolver) que tRPC ou REST

Idéal pour

API avec des consommateurs mobiles (iOS/Android) ou tiersArchitectures nécessitant une fédération dans des organisations multi-équipes/multi-servicesAPI publiques destinées à être ouvertes aux développeurs externesApplications interrogeant des graphes de données complexes et imbriquésSystèmes à grande échelle nécessitant un SLA d'entreprise et une gouvernance de schéma

Comparaison de code

tRPC
// tRPC — définition du router (serveur)
import { initTRPC } from '@trpc/server';
import { z } from 'zod';
// db = client Prisma/ORM (importé depuis un fichier séparé)

const t = initTRPC.create();

export const appRouter = t.router({
  getUser: t.procedure
    .input(z.object({ id: z.string() }))
    .query(async ({ input }) => {
      return db.user.findUnique({ where: { id: input.id } });
    }),
});

export type AppRouter = typeof appRouter;

// Client — le type du serveur est inféré automatiquement, pas de codegen
import { createTRPCClient, httpBatchLink } from '@trpc/client';
import type { AppRouter } from './server';

const client = createTRPCClient<AppRouter>({
  links: [httpBatchLink({ url: 'http://localhost:3000/trpc' })],
});

const user = await client.getUser.query({ id: '1' });
// user: { id: string; name: string; ... } — sécurité de type complète à la compilation
GraphQL
// graphql-js + @apollo/server — schéma, resolver et serveur dans un seul fichier
import { ApolloServer } from '@apollo/server';
import { startStandaloneServer } from '@apollo/server/standalone';
// db = client Prisma/ORM (importé depuis un fichier séparé)

const typeDefs = `#graphql
  type Post {
    id: ID!
    title: String!
  }

  type User {
    id: ID!
    name: String!
    posts: [Post!]!
  }

  type Query {
    user(id: ID!): User
  }
`;

const resolvers = {
  Query: {
    user: (_parent, { id }, { db }) => db.user.findUnique({ where: { id } }),
  },
  User: {
    posts: (user, _args, { db }) =>
      db.post.findMany({ where: { authorId: user.id } }),
  },
};

const server = new ApolloServer({ typeDefs, resolvers });

const { url } = await startStandaloneServer(server, {
  context: async () => ({ db }),
  listen: { port: 4000 },
});
console.log(`Serveur prêt : ${url}`);

// Requête client — seuls les champs nécessaires sont sélectionnés :
// query { user(id: "1") { name posts { title } } }

Conclusion

Décidez selon votre contexte : la seule « sécurité de type » n'est pas un argument suffisant pour GraphQL. Si vous utilisez un seul monorepo TypeScript avec un seul client web, tRPC demande presque toujours moins de travail — zéro codegen, et un changement côté serveur devient immédiatement une erreur TS côté client. Si vous avez une application mobile, une API publique ouverte aux développeurs externes ou un besoin de fédération multi-équipes, le contrat de schéma indépendant du langage de GraphQL et l'écosystème Apollo Federation offrent un avantage structurel.

Obtenir une consultation gratuite
FAQ

Questions fréquentes

Si vous travaillez dans un seul monorepo TypeScript avec un seul client web, tRPC demande moins de code et de configuration (zéro codegen, inférence TS de bout en bout — trpc.io). Si vous avez une application mobile, une API publique ouverte aux développeurs externes ou plusieurs services indépendants, le contrat de schéma de GraphQL et son écosystème de fédération (Apollo Federation) offrent une abstraction plus adaptée.

Articles de blog associés

Voir tous les articles
Toutes les comparaisons