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.
Weitere Lektüre