REST APIVSGraphQL
REST API vs GraphQL
REST, avec plus de 20 ans d'existence, affronte GraphQL, né chez Facebook. Quel paradigme de conception d'API choisir pour le backend de votre application mobile ?
tRPC vs REST Comparaison
APIs type-safe de bout en bout pour TypeScript
VS
REST
Standard de l'industrie agnostique au langage depuis 2000
9 min de lectureBackend
Comparaison des scores
Chargement du graphique...
Notation détaillée
| Catégorie | tRPC | REST |
|---|---|---|
| Performance | 9/10 | 9/10 |
| Facilité d'apprentissage | 8/10 | 10/10 |
| Écosystème | 8/10 | 10/10 |
| Communauté | 9/10 | 10/10 |
| Marché de l'emploi | 7/10 | 10/10 |
| Pérennité | 8/10 | 8/10 |
Avantages & Inconvénients
tRPC
Avantages
- Type safety du serveur au client — sans génération de code
- Validation Zod inline
- Intégration native avec React Query
- Support des subscriptions (WebSocket)
- Système de middleware + contexte
- Aucune maintenance de schéma OpenAPI/GraphQL
- Colonne vertébrale du t3-stack de Theo
- Utilisé par Vercel, Cal.com, Cloudflare
Inconvénients
- TypeScript uniquement — difficile pour une équipe polyglotte
- Client mobile/natif incompatible avec TS (REST/GraphQL nécessaire)
- Mauvais choix pour une API publique (pas de spec ouverte)
- Temps de build accru dans les grands monorepos
Idéal pour
Applications full-stack TypeScript (Next.js, Remix)APIs internes (serveur + client web dans la même équipe)Type safety critiqueItération rapide (changement de schéma répercuté instantanément au client)Projets d'ingénierie de type T3 stack
REST
Avantages
- Agnostique au langage — n'importe quel client
- Standard de l'industrie depuis plus de 25 ans
- Écosystème OpenAPI/Swagger mature
- Cache HTTP natif (Cloudflare, Varnish)
- Standard pour les API publiques
- Compatibilité directe avec les clients mobiles/natifs
- Outillage universel (Postman, curl)
- Compatibilité ascendante à long terme
Inconvénients
- Type safety manuelle (génération de code OpenAPI nécessaire)
- Beaucoup de boilerplate — routes, validateurs, types séparés
- Over-fetching/under-fetching (la raison d'être de GraphQL)
- Versioning complexe (v1, v2, dépréciation)
Idéal pour
APIs publiquesÉquipes polyglottes (iOS, Android, web, tiers)APIs stables sur le long termeScénarios à fort besoin de cache (Cloudflare edge)Conformité au standard de l'industrie
Comparaison de code
tRPC
// server/router.ts
export const appRouter = t.router({
getUser: t.procedure
.input(z.object({ id: z.string() }))
.query(async ({ input }) => {
return await db.user.findUnique({ where: { id: input.id } });
}),
});
// client (type-safe, autocomplétion !)
const user = await trpc.getUser.query({ id: "123" });
// user.name, user.email — entièrement typéREST
// OpenAPI-first
GET /api/users/:id
Response: { "id": "123", "name": "Ali", "email": "..." }
// Client (définition de type manuelle ou codegen)
const res = await fetch("/api/users/123");
const user: User = await res.json(); // Assertion de type manuelleConclusion
Monorepo TypeScript full-stack → tRPC (référence en type safety). API publique + client polyglotte → REST. GraphQL est une voie intermédiaire — type-safe et agnostique au langage, mais avec une complexité plus élevée. Approche hybride : tRPC en interne, façade REST publique.
Obtenir une consultation gratuiteFAQ
Questions fréquentes
GraphQL est un paradigme de conception distinct — un langage de requête. tRPC vs REST oppose TypeScript à l'universel. GraphQL peut faire partie d'une stratégie hybride.