gRPC en C# : plus puissant que REST, mais pas toujours

gRPC en C# : quand REST est dépassé et HTTP/1.1 un frein

Imaginez que vous êtes un pilote de Formule 1. Votre bolide peut atteindre 380 km/h, mais vous roulez dans les embouteillages urbains. Absurde, n'est-ce pas ? C'est à peu près ainsi qu'on utilise souvent gRPC en C# — un outil extrêmement puissant pour la communication inter-services — là où une simple API REST aurait suffi. Et ensuite, on s'étonne : « pourquoi c'est difficile à déboguer, pourquoi tant de code ? ».

Voyons ensemble quand utiliser gRPC est vraiment justifié, et quand il vaut mieux rester sur du HTTP/1.1 éprouvé. Spoiler : gRPC n'est pas une solution miracle. C'est un propulseur de fusée pour les bonnes tâches.

Qu'est-ce que gRPC et pourquoi C# est un terrain idéal

gRPC (Google Remote Procedure Call) est un framework d'appel de procédure à distance, construit sur HTTP/2 et Protocol Buffers. Au lieu du JSON volumineux, un format binaire compact. Au lieu d'une simple requête-réponse, des flux complets, du multiplexage et une communication bidirectionnelle.

Pourquoi C# gRPC est une tuerie ? Parce que .NET Core a été conçu dès le départ pour les microservices à forte charge. Async, Span<T>, faible niveau d'allocations — tout cela fait du duo C# + gRPC l'un des plus performants de l'industrie.

// Exemple d'un fichier .proto simple\nsyntax = "proto3";\n\nservice OrderService {\n  rpc GetOrder (OrderRequest) returns (OrderResponse);\n  rpc SubscribeOrders (OrderFilter) returns (stream OrderUpdate);\n}\n\nmessage OrderRequest {\n  string order_id = 1;\n}\n\nmessage OrderResponse {\n  string id = 1;\n  double total = 2;\n  repeated string items = 3;\n}

Après génération du code via protoc ou le package Grpc.Tools, vous obtenez une classe C# complète que vous pouvez utiliser comme une méthode ordinaire.

Quand gRPC en C# est-il vraiment nécessaire ? 5 scénarios en béton

1. Microservices à forte charge (1000+ rps)

Si votre système traite des milliers de requêtes par seconde, chaque kilo-octet superflu en JSON et chaque RTT (round-trip time) supplémentaire se traduisent par une perte d'argent. gRPC en C# offre un gain de vitesse jusqu'à 7 à 10 fois par rapport à REST/JSON grâce à :

\n
• La sérialisation binaire (Protobuf — 3 à 5 fois plus compact que JSON)
\n
• Le multiplexage HTTP/2 (un seul canal TCP pour plusieurs requêtes)
\n
• L'absence de frais généraux liés à l'analyse des en-têtes
\n

2. Streaming de données en temps réel

Vous devez transmettre des cotations boursières, des logs, de la télémétrie de capteurs IoT ou des mises à jour d'interface utilisateur ? Streaming gRPC C# est votre choix. Quatre types de flux sont pris en charge :

\n
• Unary — requête-réponse classique
\n
• Server streaming — le serveur envoie des données au client
\n
• Client streaming — le client envoie un lot de données au serveur
\n
• Bidirectional streaming — échange continu bidirectionnel
\n

// Partie serveur du streaming bidirectionnel\npublic override async Task SubscribeOrders(\n    IAsyncStreamReader<OrderFilter> requestStream,\n    IServerStreamWriter<OrderUpdate> responseStream,\n    ServerCallContext context)\n{\n    await foreach (var filter in requestStream.ReadAllAsync())\n    {\n        var update = new OrderUpdate \n        { \n            OrderId = filter.OrderId, \n            Status = "Shipped" \n        };\n        await responseStream.WriteAsync(update);\n    }\n}

3. Microservices internes d'une même équipe

gRPC est peu adapté aux API publiques (faible support des navigateurs, débogage complexe). Mais à l'intérieur d'un cluster, c'est un transport idéal. Si vous contrôlez à la fois le client et le serveur, gRPC en C# offre :

\n
• Un typage fort via les contrats .proto
\n
• La génération automatique de clients
\n
• La prise en charge de l'arrêt gracieux (graceful shutdown) et de la propagation des délais (deadline propagation)