gRPC na frontendu: proč se nepoužívá

Proč se gRPC neujalo ve frontendovém vývoji

Backendoví vývojáři jsou zvyklí na gRPC, Protobuf a Avro pro síťovou komunikaci. Při přechodu na frontend se však REST ukazuje jako nepraktický: chybí pohodlná smlouva, Swagger vyžaduje synchronizaci z obou stran. JSON způsobuje potíže — backend serializuje data, frontend se bojí breaking changes. Dotazy se mění na řetězce jako resp?.body?[i]?.creds?.card?.number.

gRPC tyto problémy řeší typizací a codegenem. Proč se tedy nepoužívá na frontendu?

Problémy codegenu z OpenAPI a Swaggeru

Automatická generace ze Swaggeru nezaručuje stabilitu. Backendový vývojář změní pole, zapomene aktualizovat specifikaci — frontend se rozbije. Organizační problémy jsou nevyhnutelné: dovolené, urgentní úkoly.

GraphQL od Facebooku sliboval řešení: striktní schéma, introspekce, codegen. Frontendoví vývojáři získali výhody, ale backend dostal nevýhody:

• Klient žádá libovolné hloubky: od { user { id name } } po rekurzivní posts { comments { author { ... } } }.
• Žádné přímé mapování na databázové modely — jsou potřeba resolvery, union types.
• Problém N+1 v dotazech.

DataLoader, persisted queries a depth limiting přidávají složitost na backendu. V Go jsou balíčky pro GraphQL obzvlášť nepohodlné.

gRPC-Web: kompromis bez výhod

gRPC-Web vypadá jako řešení: Protobuf, codegen. Ale není to skutečné gRPC.

Prohlížeče podporují HTTP/2+, ale bez plné kontroly:

• Žádné řízení spojení, rámců, streamů — vše přes fetch('/api').
• Prohlížeč → proxy přes HTTP/1.1, proxy → backend přes HTTP/2. Výhoda je pouze na backendu.
• Vyžaduje proxy infrastrukturu.

gRPC-Web se stává formátem dat, nikoli transportem. Výhody se ztrácejí.

Kořen problému: omezení prohlížeče

Prohlížeč blokuje nízkourovňový přístup kvůli bezpečnosti. JS kód z webů má přístup k síti, ale plné HTTP/2+ rámce by umožnily:

• Skenování lokální sítě.
• Útoky na localhost.
• Obcházení firewallu.
• DDoS přes uživatelská spojení.

HTTP/1.1 je bezpečný díky sandboxu: žádné sockety, omezený fetch a WebSocket. Prohlížeč sám spravuje multiplexování, kompresi hlaviček v HTTP/2+ — pro svou optimalizaci, ne pro JS.

Perspektivní alternativy

Řešení existují, ale žádné není univerzální:

• tRPC: pro TypeScript monorepo. Typy se importují přímo, bez codegenu, přes HTTP.
• Connect protocol (Buf): nadstavba nad gRPC pro fetch v prohlížeči, s codegenem.
• WebTransport: experimentální API pro HTTP/3 streamy v sandboxu. Směr vývoje.

Co je důležité

• REST dominuje díky univerzálnosti, navzdory nepohodlí smluv.
• Prohlížečové sandboxy blokují nízkourovňový HTTP/2+ pro ochranu před útoky.
• gRPC-Web ztrácí klíčové funkce: streamování, multiplexování.
• tRPC, Connect a WebTransport — nízová řešení pro specifické stacky.
• Průmysl se posouvá k sandboxovanému přístupu ke streamům přes WebTransport.

REST zůstane standardem, dokud se neobjeví univerzální smlouva. Curl se bude dál používat pro ladění.

— Editorial Team