gRPC sur le front-end : pourquoi il n'est pas utilisé

Pourquoi gRPC n'a jamais percé dans le développement frontend

Les développeurs backend sont habitués à utiliser gRPC, Protobuf et Avro pour la communication réseau. Mais lorsqu'on passe au frontend, REST devient encombrant : il n'y a pas de contrat pratique, et Swagger nécessite une synchronisation des deux côtés. JSON introduit des complexités — le backend marshalle les données, et le frontend craint les changements cassants. Les requêtes se transforment en chaînes comme resp?.body?[i]?.creds?.card?.number.

gRPC résout ces problèmes avec le typage et la génération de code. Alors pourquoi n'est-il pas utilisé côté frontend ?

Problèmes avec la génération de code depuis OpenAPI et Swagger

L'auto-génération depuis Swagger ne garantit pas la stabilité. Un développeur backend modifie des champs et oublie de mettre à jour la spécification — le frontend casse. Les problèmes organisationnels sont inévitables : vacances, tâches urgentes.

GraphQL de Facebook promettait une solution : schémas stricts, introspection, génération de code. Les développeurs frontend en ont bénéficié, mais le backend en a subi les inconvénients :

• Les clients peuvent demander des profondeurs arbitraires : de { user { id name } } à des récursions posts { comments { author { ... } } }.
• Pas de mappage direct aux modèles de base de données — des résolveurs et des types union sont nécessaires.
• Problèmes de requêtes N+1.

DataLoader, les requêtes persistantes et la limitation de profondeur ajoutent de la complexité côté backend. En Go, les packages GraphQL sont particulièrement peu pratiques.

gRPC-Web : Un compromis sans les avantages

gRPC-Web semble être une solution : Protobuf, génération de code. Mais ce n'est pas du vrai gRPC.

Les navigateurs supportent HTTP/2+, mais sans contrôle total :

• Pas de gestion de connexion, de trames ou de flux — tout passe par fetch('/api').
• Navigateur → proxy via HTTP/1.1, proxy → backend via HTTP/2. Le gain n'est que côté backend.
• Nécessite une infrastructure de proxy.

gRPC-Web devient un format de données, pas un transport. Les avantages sont perdus.

Le problème fondamental : Les limitations des navigateurs

Les navigateurs bloquent l'accès bas niveau pour des raisons de sécurité. Le code JS des sites web a accès au réseau, mais des trames HTTP/2+ complètes permettraient :

• Le balayage des réseaux locaux.
• Des attaques sur localhost.
• Le contournement des pare-feux.
• Des DDoS via les connexions utilisateurs.

HTTP/1.1 est sûr grâce au sandboxing : pas de sockets, fetch et WebSocket limités. Le navigateur gère le multiplexage et la compression d'en-têtes dans HTTP/2+ pour sa propre optimisation, pas pour le JS.

Alternatives prometteuses

Des solutions existent, mais aucune n'est universelle :

• tRPC : Pour les monorepos TypeScript. Les types sont importés directement, sans génération de code, via HTTP.
• Protocole Connect (Buf) : Une couche au-dessus de gRPC pour fetch dans les navigateurs, avec génération de code.
• WebTransport : Une API expérimentale pour les flux HTTP/3 dans un sandbox. Une direction pour le développement futur.

Points clés à retenir

• REST domine grâce à son universalité, malgré les inconvénients des contrats.
• Les sandbox des navigateurs bloquent HTTP/2+ bas niveau pour se protéger contre les attaques.
• gRPC-Web perd les fonctionnalités clés : streaming, multiplexage.
• tRPC, Connect et WebTransport sont des solutions de niche pour des piles technologiques spécifiques.
• L'industrie évolue vers un accès aux flux sandboxé via WebTransport.

REST restera la norme jusqu'à l'émergence d'un contrat universel. Curl continuera d'être utilisé pour le débogage.

— Editorial Team