06 - gRPC vs REST : le comparatif définitif
Ce que tu vas apprendre
- Comparaison point par point entre gRPC et REST
- Benchmarks de performance realistes
- L'approche hybride : REST en façade, gRPC en interne
- Comment choisir pour ton projet
Prerequisites
Le comparatif complet
J'ai deja compare gRPC et REST dans la serie microservices, mais ici je vais plus loin avec des benchmarks et des recommandations concrètes.
| Critère | REST (HTTP/JSON) | gRPC (HTTP/2 + Protobuf) |
|---|---|---|
| Serialisation | JSON texte | Protobuf binaire |
| Taille payload (100 champs) | ~2 Ko | ~600 octets |
| Serialisation/désérialisation | ~1ms | ~0.1ms |
| Typage du contrat | OpenAPI (optionnel) | .proto (obligatoire) |
| Streaming | SSE / WebSocket (a cote) | Natif (4 modes) |
| Support navigateur | Natif | gRPC-Web (proxy nécessaire) |
| Debug / lisibilité | curl, browser, Postman |
grpcurl, Postman (recent) |
| Code génération | OpenAPI Generator (variable) | protoc / buf (fiable) |
| Backward compatibility | Manuel (discipline) | Gratuite (numeros de champs) |
| Courbe d'apprentissage | Faible | Moyenne |
| Ecosysteme tooling | Énorme | En croissance |
Les benchmarks
Les chiffres varient selon les implementations, mais les ordres de grandeur sont constants.
Serialisation/désérialisation : Protobuf est 5-10x plus rapide que JSON. Sur un message de 100 champs, JSON.stringify + JSON.parse prend environ 1ms. protobuf.encode + protobuf.decode prend environ 0.1ms. Sur un seul appel, ca ne change rien. Sur 10 000 appels par seconde entre services, ca fait la différence.
Taille du payload : Protobuf produit des messages 2-3x plus petits que JSON. JSON répété les noms de champs en texte a chaque message ("user_id": "abc"). Protobuf utilise des numeros de champs en binaire. Moins de donnees = moins de bande passante = moins de latence.
Latence du premier appel : gRPC est plus lent au premier appel (handshake HTTP/2 + TLS). Mais les appels suivants sur la meme connexion sont plus rapides grace au multiplexage. Sur une serie de 1000 appels, gRPC est 30-50% plus rapide que REST en latence cumulee.
Throughput : pour du trafic intense entre services, gRPC supporte 2-5x plus de requêtes par seconde que REST sur la meme infrastructure, grâce à HTTP/2 et Protobuf.
Ces benchmarks viennent de tests internes et des donnees publiees par Google, Microsoft et Netflix. Les chiffres exacts dependent de ton infrastructure, mais les ratios sont stables.
Ou REST gagne
REST n'est pas une technologie inférieure. Il y a des domaines ou il reste le meilleur choix.
APIs publiques. Tes clients sont des navigateurs, des apps mobiles, des partenaires tiers. Ils parlent HTTP/JSON. Leur demander d'intégrer un client gRPC avec Protobuf, c'est les perdre. REST avec une bonne doc OpenAPI, c'est universel.
Prototypage rapide. Tu veux tester une idee en une journee. Écrire un fichier .proto, générer le code, configurer les outils, c'est du temps en plus. Un app.get("/users/:id", ...) en Elysia, c'est 3 lignes et ca marche.
Debug en production. "L'endpoint /orders/123 retourne quoi ?" En REST, tu fais un curl. En gRPC, tu installes grpcurl, tu regardes si la reflection est active, tu cherches le bon nom de service... C'est faisable, mais c'est plus de friction.
Caching HTTP. REST hérité de tout l'ecosysteme HTTP : CDN, cache navigateur, ETags, headers Cache-Control. gRPC n'a pas d'équivalent standardise pour le caching.
Ou gRPC gagne
Communication inter-services. C'est le terrain de jeu de gRPC. Quand deux services backend se parlent, la lisibilité humaine ne compte pas. Ce qui compte : la vitesse, le typage, la taille. gRPC gagne sur les trois.
Contrats forts. Le fichier .proto est la vérité. Si le client et le serveur ne sont pas d'accord sur le schema, ca ne compile pas. En REST, tu decouvres le problème en production quand un champ change de nom. L'article sur le versioning d'API montre pourquoi c'est critique.
Streaming. Si tu as besoin de flux de donnees en temps réel entre services -- logs, metriques, events -- gRPC streaming est la solution la plus propre. Pas de WebSocket a configurer a cote, pas de protocole supplementaire. L'article sur le streaming montre les 4 patterns.
Equipes polyglotes. L'équipe Go et l'équipe TypeScript partagent le meme fichier .proto. Le code généré est idiomatique dans chaque langage. Pas de "je pensais que ce champ s'appelait userId, pas user_id".
L'approche hybride : la bonne réponse
Pour la plupart des architectures microservices, la réponse n'est pas "gRPC OU REST". C'est les deux.
[Internet]
|
[API Gateway]
(REST/JSON)
/ | \
[Service A] [Service B] [Service C]
| | |
+---gRPC-----+---gRPC-----+
(communication interne)REST en façade : l'API Gateway expose des endpoints REST/JSON pour les clients externes (navigateurs, apps mobiles, partenaires). C'est la face publique. OpenAPI pour la doc, JSON pour le debug, HTTP classique pour le caching.
gRPC en interne : les services communiquent entre eux en gRPC. Typage fort, performance, streaming. Les clients externes ne voient jamais le gRPC.
L'API Gateway traduit entre les deux mondes. Le client envoie du JSON, le gateway appelle le service en gRPC, et retourne du JSON. Envoy, Kong, et Traefik font ca nativement. Tu peux aussi coder ton propre gateway avec Elysia qui appelle des clients gRPC.
gRPC-Web : le compromis pour le navigateur
Si tu veux que le navigateur appelle directement du gRPC (sans passer par un gateway REST), il y a gRPC-Web. C'est un sous-ensemble de gRPC qui fonctionne avec HTTP/1.1 et les navigateurs.
En pratique, ca nécessité un proxy (Envoy) qui traduit gRPC-Web en gRPC natif. Ca marche, mais c'est une couche supplementaire. Pour la plupart des projets, un API Gateway REST est plus simple.
Mon opinion pour paltemps.fr
Sur paltemps.fr, REST est le bon choix. Un seul processus Bun/Elysia, pas de communication inter-services, un frontend web qui consomme du JSON. Ajouter gRPC n'apporterait rien.
Si paltemps.fr evoluait vers une architecture a 10 services avec des équipes separees, voici ce que je ferais :
- Garder REST pour l'API publique (le frontend web)
- Ajouter gRPC pour la communication entre les services internes
- Utiliser un API Gateway (Caddy + un layer de traduction) pour le pont entre les deux
- Messaging asynchrone (NATS ou Redis Streams) pour les events fire-and-forget
Mais ca, c'est pour un projet avec 10 services et 20 développeurs. Pas pour un monolithe avec un seul dev. La serie Microservices explique quand ce genre de décisions se justifie.
L'arbre de décision
Pour choisir entre REST et gRPC, pose-toi ces questions dans l'ordre :
- C'est une API publique ? -> REST. Point.
- C'est de la communication inter-services ? -> gRPC.
- Tu as besoin de streaming ? -> gRPC.
- Tu as une seule équipe et un seul langage ? -> REST suffit probablement.
- Tu as besoin de contrats types stricts entre équipes ? -> gRPC.
- Tu fais du prototypage rapide ? -> REST, tu migreras si besoin.
Résumé
- gRPC est 5-10x plus rapide en sérialisation et 2-3x plus compact que REST
- REST gagne pour les APIs publiques, le debug, et le prototypage
- gRPC gagne pour le trafic inter-services, le typage fort, et le streaming
- L'approche hybride (REST en façade, gRPC en interne) est le pattern standard
- Pour un monolithe comme paltemps.fr, REST suffit. gRPC se justifie quand tu as des services internes.
Article précédent : 05 - gRPC en production
Suivant : 07 - Glossaire
Serie liee : Microservices : de la theorie a la pratique -- le contexte architectural dans lequel gRPC s'inscrit.