Wann würdest du gRPC statt einer REST-API einsetzen?

Nimm gRPC für interne Service-zu-Service-Aufrufe, bei denen du beide Enden kontrollierst und einen strikten Vertrag, binäre Kodierung, Streaming und niedrigere Latenz willst. Nimm REST über JSON für öffentliche APIs, Browser-Clients und alles, was davon profitiert, lesbar, cachebar und mit curl debugbar zu sein. Der Trade ist ein generiertes, versioniertes Schema plus bessere Performance gegen universelles Tooling und einfache Interoperabilität.

Ich teile es danach auf, wer der Konsument ist. Für alles, womit ein Browser oder ein Drittanbieter spricht, bleibe ich bei REST mit JSON, weil es jeder aufrufen kann, du am Edge cachen kannst, und du es um zwei Uhr nachts mit curl reproduzieren kannst, wenn etwas kaputtgeht. Für internen Service-zu-Service-Traffic, wo mir beide Seiten gehören, verdient gRPC seinen Platz. Du bekommst eine proto-Datei als durchgesetzten Vertrag, generierte Clients in jeder Sprache, damit niemand einen Serializer von Hand baut, echtes bidirektionales Streaming und deutlich weniger Bytes auf der Leitung. Die Kosten sind aber real. Browser brauchen eine Proxy-Schicht, dein Load Balancer muss HTTP/2 sauber beherrschen, und ein binäres Payload zu debuggen braucht mehr Setup. In einem System, an dem ich gearbeitet habe, haben wir den öffentlichen Rand als REST gelassen und gRPC zwischen Gateway und internen Services genutzt, was uns intern Typsicherheit gab, ohne dass ein einziger Kunde etwas ändern musste.