gRPC en el frontend: por qué no se usa

Por qué gRPC nunca se popularizó en el desarrollo frontend

Los desarrolladores backend están acostumbrados a usar gRPC, Protobuf y Avro para la comunicación en red. Pero al pasar al frontend, REST se vuelve engorroso: no hay un contrato conveniente, y Swagger requiere sincronización desde ambos lados. JSON introduce complejidades: el backend serializa los datos, y el frontend teme cambios que rompan la compatibilidad. Las peticiones se convierten en cadenas como resp?.body?[i]?.creds?.card?.number.

gRPC resuelve estos problemas con tipado y generación de código. Entonces, ¿por qué no se usa en el frontend?

Problemas con la generación de código desde OpenAPI y Swagger

La generación automática desde Swagger no garantiza estabilidad. Un desarrollador backend cambia campos y olvida actualizar la especificación: el frontend se rompe. Los problemas organizativos son inevitables: vacaciones, tareas urgentes.

GraphQL de Facebook prometió una solución: esquemas estrictos, introspección, generación de código. Los desarrolladores frontend se beneficiaron, pero el backend obtuvo las desventajas:

• Los clientes pueden solicitar profundidades arbitrarias: desde { user { id name } } hasta recursivo posts { comments { author { ... } } }.
• No hay mapeo directo a modelos de base de datos: se necesitan resolvers y tipos unión.
• Problemas de consultas N+1.

DataLoader, consultas persistentes y limitación de profundidad añaden complejidad en el backend. En Go, los paquetes GraphQL son particularmente inconvenientes.

gRPC-Web: Un compromiso sin las ventajas

gRPC-Web parece una solución: Protobuf, generación de código. Pero no es gRPC real.

Los navegadores soportan HTTP/2+, pero sin control total:

• Sin gestión de conexión, frames o streams: todo pasa por fetch('/api').
• Navegador → proxy vía HTTP/1.1, proxy → backend vía HTTP/2. La ganancia es solo en el backend.
• Requiere infraestructura de proxy.

gRPC-Web se convierte en un formato de datos, no en un transporte. Las ventajas se pierden.

El problema de raíz: Limitaciones del navegador

Los navegadores bloquean el acceso de bajo nivel por razones de seguridad. El código JS de sitios web tiene acceso a red, pero frames HTTP/2+ completos permitirían:

• Escaneo de redes locales.
• Ataques a localhost.
• Evasión de firewalls.
• DDoS a través de conexiones de usuarios.

HTTP/1.1 es seguro gracias al sandboxing: sin sockets, fetch y WebSocket limitados. El navegador gestiona multiplexación y compresión de cabeceras en HTTP/2+ para su propia optimización, no para JS.

Alternativas prometedoras

Existen soluciones, pero ninguna es universal:

• tRPC: Para monorepos TypeScript. Los tipos se importan directamente, sin generación de código, sobre HTTP.
• Protocolo Connect (Buf): Una capa sobre gRPC para fetch en navegadores, con generación de código.
• WebTransport: Una API experimental para streams HTTP/3 en un sandbox. Una dirección para desarrollo futuro.

Conclusiones clave

• REST domina debido a su universalidad, a pesar de las inconveniencias del contrato.
• Los sandboxes del navegador bloquean HTTP/2+ de bajo nivel para proteger contra ataques.
• gRPC-Web pierde características clave: streaming, multiplexación.
• tRPC, Connect y WebTransport son soluciones de nicho para stacks tecnológicos específicos.
• La industria se mueve hacia acceso sandboxed a streams vía WebTransport.

REST seguirá siendo el estándar hasta que surja un contrato universal. Curl continuará usándose para depuración.

— Editorial Team