gRPC zwischen .NET-Microservices
Die .proto-Datei als einzige Quelle der Wahrheit
.proto -Datei: Sie beschreibt die Nachrichten und den Service, unabhängig von der Sprache. Das ist der Vertrag — weder Client noch Server schreiben ihn von Hand. Darin deklariert man einen service Pricing , der einen rpc GetQuote (QuoteRequest) -Aufruf bereitstellt, der ein QuoteReply zurückgibt. Jedes Feld ist nummeriert ( string sku = 1; , int32 quantity = 2; ) — diese Nummern sind der Schlüssel zur Abwärtskompatibilität: Man darf sie niemals wiederverwenden.
.csproj über <Protobuf Include="pricing.proto" /> . Das Package Grpc.Tools generiert dann zur Kompilierzeit die Server-Basisklasse und den typisierten Client — keine DTOs müssen manuell kopiert werden:
Typisierter Server und Client
Pricing.PricingBase ab und überschreibt die Methode. Kein Routing muss verdrahtet werden, keine manuelle Deserialisierung: Man empfängt eine stark typisierte Nachricht.
HttpClient . Man injiziert den generierten Client über AddGrpcClient und ruft ihn wie eine lokale Methode auf:
Streaming als entscheidendes Argument
stream liefert Ergebnisse fortlaufend aus; ein bidirektionaler stream öffnet einen Full-Duplex-Kanal, ideal für Telemetrie oder Chat. Man schreibt in einen IServerStreamWriter<T> und der Client iteriert mit await foreach — ohne Polling, ohne mühsam zusammengebauten WebSocket.
gRPC vs. REST: eine bewusste Wahl treffen
Der gesunde Reflex: REST als öffentliche Fassade, gRPC im Inneren . Der .proto-Vertrag wird so zur formalen Grenze zwischen Ihren Services — versioniert, geteilt, vom Compiler geprüft.