En Riiid, que opera Santa TOEIC, usamos gRPC/Protobuf de forma muy activa.
Poco después de que entré a Riiid, nos informaron que en adelante todas las API que el equipo de backend ofreciera al frontend (móvil/web) se unificarían en gRPC.
Para usar el stack de gRPC/Protobuf en frontend web, antes existían métodos como usar protoc con un plugin de JS/TS o utilizar Protobuf.js.
El plugin oficial de JS para protoc tenía el problema de generar código con un estilo muy antiguo, y los plugins del ecosistema tampoco cumplían con todos nuestros requisitos. Además, era incómodo cargar siempre con la dependencia de un binario nativo (protoc). (Últimamente también existe el problema de que es difícil instalar protoc en equipos M1.)
Habíamos creado varios productos usando Protobuf.js, pero cuando todos los productos de la empresa empezaron a usar Protobuf para todas las interfaces de comunicación entre plataformas, nos dimos cuenta de que Protobuf.js no era lo suficientemente maduro para el nivel que necesitábamos.
Nos topamos con varios problemas, como que si el nombre de un mensaje era igual podía confundirse con un mensaje dentro de otro namespace, o que si en el namespace global después de un enum venía una declaración de mensaje no se generaba el código del tipo de mensaje, o que las definiciones de tipos de TypeScript no coincidían con el comportamiento del JS generado.
En este proceso, para construir un sistema que compilara solo los esquemas protobuf necesarios para un producto específico, creamos un gestor de paquetes de protobuf llamado pollapo.
(En ese momento había otros administradores de dependencias de protobuf, pero tenían bugs o problemas como no soportar dependencias anidadas. Además, la funcionalidad de gestión de paquetes que ofrecía buf estaba solo en un post del blog indicando que estaba en desarrollo, y no estuvo terminada hasta después de que creamos pollapo y completamos la migración interna.)
Con pollapo redujimos enormemente la cantidad de esquemas compilados por producto, y aunque disminuyeron los bugs causados por cosas como nombres de mensajes iguales, seguían existiendo errores y problemas de build, así que para resolverlos terminamos creando nosotros mismos un compilador de protobuf a TypeScript.
Santa TOEIC ya completó la sustitución total de protobuf.js por pbkit.
Las apps desarrolladas en Riiid, incluyendo Santa TOEIC, usan WebView de forma intensiva.
WebView se comunica con nativo para obtener información del dispositivo/usuario o de los contenidos que se muestran, y esa interfaz también la definimos usando esquemas de servicios Protobuf.
pbkit ofrece, al generar código de servicios, una interfaz que permite reemplazar la capa de red por un protocolo distinto de gRPC.
Los ingenieros de frontend web que usan el compilador de pbkit no necesitan saber si al comunicarse con el entorno nativo móvil están haciendo solicitudes por gRPC o si se comunican mediante el protocolo App Bridge acordado con los ingenieros móviles.
Y como también desarrollamos directamente la extensión de Chrome, es posible revisar cómodamente en la pestaña de pbkit de las herramientas para desarrolladores de Chrome todo lo que se comunica con móvil, igual que si se viera la pestaña de red.
Como creamos nosotros mismos el compilador de esquemas protobuf, pensamos que sería fácil implementar funciones como Go to Definition en el editor de código, así que también hicimos una extensión para VSCode.
Hasta ahora, las extensiones de protobuf para VSCode solo ofrecían funciones como resaltado de sintaxis, pero la extensión pbkit para VSCode incluye una función de Go to Definition que sí funciona correctamente.
A futuro planeamos desarrollar soporte para otros lenguajes como swift/kotlin/python, casos de uso del lado del servidor, herramientas de generación de documentación y herramientas de linting/formateo.
También estamos buscando ingenieros para desarrollar estas herramientas junto con nosotros: https://riiid.com/ko/career/dx-software-engineer
Les pedimos mucho interés.
Repositorio de pbkit: https://github.com/pbkit/pbkit
Extensión de VSCode: https://marketplace.visualstudio.com/items?itemName=pbkit.vscode-pbkit
Extensión de Chrome: https://chrome.google.com/webstore/detail/pbkit-devtools/fjacmiijeihblfhobghceofniolonhca
9 comentarios
¡¡Lo estamos usando muy bien en Karrot!! ( _ _ )
Estamos intentando aprovecharlo bien para el mallado interno de APIs jaja
¡Oh, qué impresionante!
Por cierto, si en la empresa ya lo están usando lo suficiente como para ponerlo en producción, creo que ya podrían dejar de usar una versión con pinta de pre-alpha como la v0.0.44.
Me parece que habrá gente que no lo use solo por ver el número de versión 😢
Vaya, así que hiciste el compilador tú mismo. ¡Está genial! (Tenía curiosidad por cómo se genera el código de golang, pero parece que por ahora solo soporta deno y node.js). Yo suelo usar protoc o buf junto con ts-proto, así que me da curiosidad cómo difiere el código de ts que se genera frente a ts-proto.
Siento que de algún modo está dando una vuelta innecesaria https://github.com/trpc/trpc
bichi / Si la API del servidor se ofrece mediante el protocolo gRPC, ¿no sería que trcp no está pensado para soportar eso~?
Estoy de acuerdo en que usar el stack de gRPC/Protobuf no es lo ideal. (No fue porque yo quisiera usarlo, sino por circunstancias de la empresa)
Aun así, como tRPC define la interfaz usando zod, parece ideal cuando se usa TypeScript en todas las plataformas.
En nuestro entorno, donde escribimos el servidor en Kotlin, creo que sería difícil usarlo, y tampoco parece adecuado cuando se comunica con móviles nativos (Swift, Kotlin).
Los artículos relacionados con gRPC siempre son bienvenidos :)
Guau, hasta tiene extensiones para VS/Chrome en el código... ¡qué genial! Los apoyo.
Como escribieron la presentación súper bien, da la impresión de que quienes lleguen a través de GeekNews obtendrán incluso más información que quienes solo visiten el repo ^^;
Si quienes están usando Protobuf actualmente dejan un comentario, creo que sería de mucha ayuda.