gRPC im Frontend: Warum wird es nicht verwendet

Warum sich gRPC im Frontend nie durchgesetzt hat

Backend-Entwickler sind es gewohnt, gRPC, Protobuf und Avro für die Netzwerkkommunikation zu nutzen. Doch beim Wechsel zum Frontend wird REST umständlich: Es gibt keinen praktischen Vertrag, und Swagger erfordert Synchronisation von beiden Seiten. JSON bringt Komplexitäten mit sich – das Backend marshallt Daten, und das Frontend fürchtet Breaking Changes. Anfragen werden zu Ketten wie resp?.body?[i]?.creds?.card?.number.

gRPC löst diese Probleme mit Typisierung und Code-Generierung. Warum wird es dann nicht im Frontend eingesetzt?

Probleme mit Code-Generierung aus OpenAPI und Swagger

Automatische Generierung aus Swagger garantiert keine Stabilität. Ein Backend-Entwickler ändert Felder und vergisst, die Spezifikation zu aktualisieren – das Frontend bricht. Organisatorische Probleme sind unvermeidlich: Urlaub, dringende Aufgaben.

GraphQL von Facebook versprach eine Lösung: strikte Schemata, Introspection, Code-Generierung. Frontend-Entwickler profitierten, aber das Backend bekam die Nachteile:

• Clients können beliebige Tiefen anfordern: von { user { id name } } bis zu rekursiven posts { comments { author { ... } } }.
• Keine direkte Abbildung auf Datenbankmodelle – Resolver und Union-Types sind nötig.
• N+1 Query-Probleme.

DataLoader, persistierte Queries und Tiefenbegrenzung erhöhen die Komplexität im Backend. In Go sind GraphQL-Pakete besonders unpraktisch.

gRPC-Web: Ein Kompromiss ohne die Vorteile

gRPC-Web sieht nach einer Lösung aus: Protobuf, Code-Generierung. Aber es ist kein echtes gRPC.

Browser unterstützen HTTP/2+, aber ohne volle Kontrolle:

• Keine Verbindungs-, Frame- oder Stream-Verwaltung – alles läuft über fetch('/api').
• Browser → Proxy über HTTP/1.1, Proxy → Backend über HTTP/2. Der Gewinn liegt nur im Backend.
• Erfordert Proxy-Infrastruktur.

gRPC-Web wird zu einem Datenformat, nicht zu einem Transport. Die Vorteile gehen verloren.

Das Grundproblem: Browser-Beschränkungen

Browser blockieren aus Sicherheitsgründen Low-Level-Zugriff. JS-Code von Websites hat Netzwerkzugriff, aber volle HTTP/2+-Frames würden ermöglichen:

• Scannen lokaler Netzwerke.
• Angriffe auf localhost.
• Firewall-Umgehung.
• DDoS über Nutzerverbindungen.

HTTP/1.1 ist dank Sandboxing sicher: keine Sockets, begrenztes Fetch und WebSocket. Der Browser verwaltet Multiplexing und Header-Kompression in HTTP/2+ für eigene Optimierung, nicht für JS.

Vielversprechende Alternativen

Lösungen existieren, aber keine ist universell:

• tRPC: Für TypeScript-Monorepos. Typen werden direkt importiert, ohne Code-Generierung, über HTTP.
• Connect-Protokoll (Buf): Eine Schicht über gRPC für Fetch in Browsern, mit Code-Generierung.
• WebTransport: Eine experimentelle API für HTTP/3-Streams in einer Sandbox. Eine Richtung für zukünftige Entwicklung.

Wichtige Erkenntnisse

• REST dominiert aufgrund von Universalität, trotz Vertrags-Unannehmlichkeiten.
• Browser-Sandboxen blockieren Low-Level-HTTP/2+ zum Schutz vor Angriffen.
• gRPC-Web verliert Schlüsselfunktionen: Streaming, Multiplexing.
• tRPC, Connect und WebTransport sind Nischenlösungen für spezifische Tech-Stacks.
• Die Industrie bewegt sich zu sandboxed Stream-Zugriff über WebTransport.

REST bleibt Standard, bis ein universeller Vertrag entsteht. Curl wird weiterhin zum Debuggen verwendet.

— Editorial Team