Conectar una aplicación web directamente a servicios gRPC no es trivial: los navegadores no soportan gRPC de forma nativa, y por eso necesitas un proxy intermediario como gRPC-Web. Aquí entenderás por qué ocurre esto, qué papel juega Envoy y cuándo conviene mantener gRPC solo en el backend.

¿Por qué un navegador no puede consumir gRPC directamente?

La razón es técnica y tiene que ver con cómo está construido gRPC. Sus mejoras de rendimiento se apoyan en HTTP/2 y en los Protobuffers, dos componentes que el navegador no expone de manera nativa para que puedas invocar métodos gRPC desde JavaScript. En la práctica, no existe una API del browser que te deje llamar un servicio gRPC como llamarías a un endpoint REST.

Y ahí es donde entra el concepto de proxy. Piensa en el proxy como un intermediario que se sienta entre tu navegador y los microservicios escritos en gRPC. El browser habla con el proxy, y el proxy decide a qué microservicio enrutar la llamada.

¿Qué es un proxy en gRPC-Web? Es una capa intermedia que traduce las peticiones del navegador a llamadas gRPC reales. El cliente web se comunica con el proxy y el proxy reenvía la solicitud al microservicio correspondiente.

¿Qué es gRPC-Web y cómo se conecta con Envoy?

gRPC-Web es el proyecto oficial de gRPC que implementa esta comunicación usando JavaScript, el lenguaje que corre en los browsers. En su repositorio encontrarás documentación extensa para llevar proyectos gRPC al navegador.

La pieza que hace el trabajo pesado es Envoy, un proxy escrito en C++ que no es exclusivo de gRPC sino que sirve como proxy para múltiples tipos de servicios. gRPC-Web se apoya en Envoy para enrutar y traducir las peticiones que llegan desde el cliente web hacia los microservicios gRPC del backend.

¿Cuál es el costo de añadir este proxy?

La parte incómoda: estás sumando una capa extra a tu arquitectura. Cada salto introduce latencia, y eso choca con la promesa original de gRPC, que es maximizar el rendimiento. Tu aplicación gana compatibilidad con el navegador, pero pierde un poco del performance que justificaba elegir gRPC en primer lugar.

¿Conviene usar gRPC-Web o un REST API tradicional? Si tu prioridad es la velocidad pura entre servicios de backend, gRPC sin proxy es mejor. Si necesitas que un browser consuma esos servicios, evalúa si la latencia del proxy compensa frente a un REST API o WebSockets.

¿Cuándo usar gRPC para frontend y cuándo solo para backend?

La pregunta de fondo es de diseño: ¿gRPC es un buen caso de uso cuando un navegador accede a múltiples servicios, o brilla más como protocolo de comunicación entre servicios que solo viven en el backend?

Algunas señales para decidir:

• Si tus consumidores son exclusivamente otros microservicios, gRPC puro es ideal porque aprovechas HTTP/2 y Protobuffers sin intermediarios.
• Si tu consumidor principal es un navegador, considera el costo del proxy y compáralo con un REST API o WebSockets.
• Si necesitas ambos mundos, gRPC-Web con Envoy es la ruta documentada y soportada.

¿Cómo conectar tu app de registro de estudiantes al browser?

Aquí viene el reto. Tienes una aplicación que registra estudiantes y tests usando gRPC, y la idea es exponerla a un navegador. Tienes dos caminos.

El primero es usar gRPC-Web con el proxy basado en Envoy: ganas tiempo porque la herramienta ya existe, pero te atas a su forma de trabajar.

El segundo es construir tu propio servidor web que actúe como proxy entre el browser y los microservicios gRPC. Inviertes más tiempo, pero ganas flexibilidad total para decidir cómo procesar las peticiones, qué autenticación aplicar y cómo enrutar.

También puedes mirar atrás y combinar lo aprendido en cursos previos de Go: levantar un REST API o usar WebSockets como capa de comunicación con el frontend, dejando gRPC solo entre microservicios internos.

Habilidades y conceptos clave de la clase

Antes de cerrar, vale la pena fijar las ideas técnicas que aparecieron:

• gRPC-Web [00:50]: implementación oficial en JavaScript para consumir servicios gRPC desde el navegador.
• Proxy [00:35]: capa intermedia entre el browser y los microservicios gRPC; necesaria porque el navegador no soporta gRPC nativo.
• Envoy [01:30]: proxy escrito en C++ sobre el que se apoya gRPC-Web, no exclusivo de gRPC.
• HTTP/2 y Protobuffers [00:10]: componentes que dan a gRPC su rendimiento, pero que no están expuestos de forma nativa en el browser.
• Trade-off de latencia [00:40]: añadir un proxy mejora compatibilidad pero introduce un salto extra que afecta el performance.

¿Tú qué prefieres: usar gRPC-Web con Envoy o construir tu propio proxy con Go? Déjame en los comentarios el enlace a tu solución y cómo decidiste resolver la conexión entre el navegador y tus servicios gRPC.