gRPC w frontendzie: dlaczego nie używają

Dlaczego gRPC nie przyjął się w rozwoju frontendu

Deweloperzy backendu przyzwyczaili się do gRPC, Protobuf i Avro do komunikacji sieciowej. Ale przy przejściu na frontend REST okazuje się uciążliwy: brak wygodnego kontraktu, Swagger wymaga synchronizacji z obu stron. JSON powoduje trudności — backend marshaluje dane, frontend obawia się breaking changes. Zapytania zamieniają się w łańcuchy jak resp?.body?[i]?.creds?.card?.number.

gRPC rozwiązuje te problemy przez typizację i codegen. Dlaczego więc nie jest używany na froncie?

Problemy codegen z OpenAPI i Swagger

Autogeneracja ze Swagger nie gwarantuje stabilności. Deweloper backendu zmienia pola, zapomina zaktualizować specyfikację — frontend się psuje. Problemy organizacyjne są nieuniknione: urlopy, pilne zadania.

GraphQL od Facebooka obiecywał rozwiązanie: ścisła schemat, introspection, codegen. Frontendowcy zyskali, ale backend dostał minusy:

• Klient żąda dowolnych głębokości: od { user { id name } } do rekurencyjnych posts { comments { author { ... } } }.
• Brak bezpośredniego mapowania na modele bazy danych — potrzebne są resolvery, union types.
• Problem N+1 w zapytaniach.

DataLoader, persisted queries i depth limit dodają złożoności na backendzie. W Go pakiety dla GraphQL są szczególnie niewygodne.

gRPC-Web: kompromis bez zalet

gRPC-Web wygląda jak rozwiązanie: Protobuf, codegen. Ale to nie jest prawdziwe gRPC.

Przeglądarki wspierają HTTP/2+, ale bez pełnej kontroli:

• Brak zarządzania połączeniem, ramkami, strumieniami — wszystko przez fetch('/api').
• Przeglądarka → proxy przez HTTP/1.1, proxy → backend przez HTTP/2. Zysk tylko na backendzie.
• Wymagana infrastruktura proxy.

gRPC-Web staje się formatem danych, a nie transportem. Plusy znikają.

Źródło problemu: ograniczenia przeglądarki

Przeglądarka blokuje niskopoziomowy dostęp ze względów bezpieczeństwa. Kod JS z witryn ma dostęp do sieci, ale pełne ramki HTTP/2+ pozwoliłyby na:

• Skanowanie sieci lokalnej.
• Ataki na localhost.
• Obejście firewall.
• DDoS przez połączenia użytkownika.

HTTP/1.1 jest bezpieczny dzięki sandbox: brak gniazd, ograniczony fetch i WebSocket. Przeglądarka sama zarządza multipleksowaniem, kompresją nagłówków w HTTP/2+ — dla własnej optymalizacji, nie dla JS.

Perspektywiczne alternatywy

Rozwiązania istnieją, ale żadne nie jest uniwersalne:

• tRPC: dla monorepo TypeScript. Typy importowane bezpośrednio, bez codegen, przez HTTP.
• Connect protocol (Buf): nakładka na gRPC dla fetch w przeglądarce, z codegen.
• WebTransport: eksperymentalny API dla strumieni HTTP/3 w sandbox. Kierunek rozwoju.

Co jest ważne

• REST dominuje dzięki uniwersalności, mimo niewygód kontraktów.
• Sandboxy przeglądarek blokują niskopoziomowy HTTP/2+ dla ochrony przed atakami.
• gRPC-Web traci kluczowe funkcje: streaming, multipleksowanie.
• tRPC, Connect i WebTransport — niszowe rozwiązania dla specyficznych stosów.
• Branża zmierza do sandboxed dostępu do strumieni przez WebTransport.

REST pozostanie standardem, dopóki nie pojawi się uniwersalny kontrakt. Curl będzie nadal używany do debugowania.

— Editorial Team