gRPC macht innerhalb von Service-Grenzen am meisten Sinn_
gRPC ist für interne Dienste überzeugend, weil es strikte Verträge, Code-Generierung und einen effizienten Transport bietet, aber es ist kein universeller Ersatz für REST.
Teams übernehmen gRPC normalerweise aus einem von zwei Gründen.
Der gute Grund ist, dass sie eine wachsende Anzahl interner Dienste haben und einen strikteren, besser ausgestatteten Vertrag als ad hoc JSON über HTTP möchten. Der schlechte Grund ist, dass sie gehört haben, REST sei "legacy", und jedes API ersetzen wollen, ohne klar zu sein, welches Problem sie lösen.
gRPC ist im ersten Fall hervorragend. Im zweiten Fall ist es oft unnötig.
Was gRPC tatsächlich verbessert
Bei internen Service-zu-Service-Aufrufen bietet gRPC gleichzeitig einige bedeutende Vorteile:
einen Schema-ersten Vertrag in .proto-Dateien
generierte Clients und Server
kompakte binäre Serialisierung
integrierte Streaming-Muster
Diese Kombination reduziert viel Schnittstellendrift zwischen den Diensten.
Hier ist die Art von Vertrag, der besser altert als eine lose dokumentierte JSON-Struktur:
syntax = "proto3";service UserService { rpc GetUser (GetUserRequest) returns (GetUserResponse);}message GetUserRequest { string id = 1;}message GetUserResponse { string id = 1; string email = 2; bool active = 3;}
Sobald dieses Schema existiert, lebt der Vertrag nicht mehr in Slack-Nachrichten und halb aktualisierten Wiki-Seiten.
Wo es in der Praxis hilft
Der größte Gewinn liegt normalerweise nicht in der Rohserialisierungs-Geschwindigkeit. Es ist die Disziplin der Schnittstelle.
Wenn fünf Dienste alle mit dem gleichen Abrechnungs- oder Identitätsdienst kommunizieren müssen, reduzieren generierte Clients und ein stabiles Schema viele unbeabsichtigte Beschädigungen. Sie hören auf, Payload-Typen in jedem Verbraucher manuell zu schreiben, und beginnen, die Service-Grenze wie eine echte Produktoberfläche zu behandeln.
Das zählt über die Zeit mehr, als ein paar Bytes von der Übertragung zu sparen.
Wo REST immer noch gewinnt
REST hat immer noch starke Vorteile:
es ist einfach mit gängigen Werkzeugen zu debuggen
es funktioniert natürlich mit Browsern
es mappt sauber auf öffentliche APIs
es passt gut zu Caching und HTTP-Semantiken
Deshalb enden viele Systeme mit einem geteilten Modell:
REST oder HTTP JSON am Rand
gRPC innerhalb des Mesh
Dies ist oft die pragmatischste Architektur.
Die Kompromisse
gRPC ist nicht kostenlos.
Sie übernehmen:
protobuf-Schema-Management
generierten Code in der Toolchain
weniger bequeme Inspektion als bei reinem JSON
mehr Reibung für browser-native Clients, es sei denn, Sie fügen gRPC-Web oder eine andere Brücke hinzu
Das ist in einer kontrollierten Umgebung in Ordnung. Es ist weniger in Ordnung, wenn die API breit konsumierbar sein muss.
Eine gute Entscheidungsregel
Verwenden Sie gRPC, wenn:
die Aufrufer hauptsächlich interne Dienste sind
starke Verträge wichtig sind
Sie generierte Clients über Teams oder Sprachen hinweg wünschen
Bleiben Sie bei REST, wenn:
die API öffentlich ist
Browser die primären Verbraucher sind
HTTP-Semantiken und Caching wichtiger sind als die Ergonomie von RPC
Das Ziel ist nicht, einen Gewinner für jedes System auszuwählen. Das Ziel ist, aufhören, ein Protokoll aus Gewohnheit zu verwenden.