BloomRPC fue la respuesta a una pregunta que todo desarrollador de gRPC eventualmente se hace: "¿dónde está mi Postman para gRPC?" Carga un archivo .proto, obtén un cuerpo de solicitud JSON editable, presiona enviar. Era simple, era gratuito, y obtuvo alrededor de 9,000 estrellas en GitHub haciendo una cosa bien. Luego, el 4 de enero de 2023, el repositorio fue archivado. El README no se anda con rodeos: el proyecto se estancó, los problemas se acumularon y los mantenedores ahora afirman claramente que "su uso ya no es recomendado". Te señalan la lista de awesome-grpc y te desean suerte.
Aquí está la respuesta directa: Apidog es la mejor alternativa a BloomRPC para la mayoría de los equipos, porque no solo reemplaza la ventana de carga de .proto. Admite los cuatro tipos de llamadas gRPC (unaria, streaming de servidor, streaming de cliente y streaming bidireccional), importa archivos .proto desde una ruta local, una URL o reflexión de servidor, y pone tu trabajo de gRPC en el mismo proyecto que tus puntos finales REST, WebSocket y GraphQL, con documentación, colaboración y configuraciones de depuración guardadas incluidas. Si solo necesitas una llamada desechable desde una terminal, existen herramientas más ligeras, y también las cubriremos honestamente. Este artículo explica qué murió con BloomRPC, con qué reemplazarlo y exactamente cómo migrar.
Qué fue BloomRPC y por qué desapareció
BloomRPC se lanzó en 2018 como una aplicación de escritorio Electron con un solo trabajo: realizar llamadas gRPC sin escribir un cliente. Importabas tus archivos .proto, listaba los servicios y métodos, generaba un esqueleto JSON para cada mensaje de solicitud y te permitía editar metadatos y enviarlos. Para llamadas unarias y streaming básico, estaba bien, y "bien y gratis" lo convirtió en la GUI gRPC predeterminada durante años.
El aviso de archivo termina limpiamente esa era. Un repositorio archivado significa que no hay correcciones de errores, no hay actualizaciones de dependencias y no hay lanzamientos. Para una aplicación Electron, eso no es un estado neutral: las versiones de Chromium y Node empaquetadas envejecen y quedan sin soporte de seguridad, la sintaxis de proto más nueva y las características de gRPC no se manejan, y los errores conocidos (BloomRPC tuvo algunos de larga data relacionados con importaciones de proto y ciertos flujos de streaming) se quedan exactamente donde están. Los mantenedores fueron honestos al respecto, lo cual es más de lo que muchos proyectos muertos logran. El mensaje es: deja de instalar esto.
La gente sigue buscando BloomRPC porque la forma de la herramienta era la correcta. La pregunta es si se reemplaza la forma (otra ventana gRPC independiente) o se arregla la fragmentación subyacente: la mayoría de los equipos que ejecutan gRPC también ejecutan REST, y probarlos en dos herramientas desconectadas siempre fue el impuesto que BloomRPC cobraba silenciosamente. Hemos escrito antes sobre lo que hace que un buen cliente gRPC; la versión corta es que "carga protos, envía llamadas" ahora es un requisito básico, y los diferenciadores viven por encima de eso.
La respuesta: Apidog
Apidog es una plataforma de desarrollo de API utilizada por más de 500,000 desarrolladores, que cubre diseño, depuración, pruebas, simulación y documentación. Su soporte gRPC, según la documentación oficial, cubre lo que hizo BloomRPC y las partes que BloomRPC nunca terminó:
- Los cuatro tipos de llamadas. Se admiten llamadas unarias, streaming de servidor, streaming de cliente y streaming bidireccional. Las llamadas de streaming funcionan como una sesión de WebSocket: abre la llamada, luego escribe y envía mensajes desde una pestaña de Mensajes mientras una vista de línea de tiempo muestra los mensajes enviados y recibidos en orden. El soporte de streaming de BloomRPC era parcial y tenía errores al final; aquí es una característica documentada.
- Tres formas de importar su definición de API. Carga un archivo .proto local, importa desde una URL o usa la reflexión del servidor para obtener servicios directamente de un servidor gRPC en ejecución sin tener archivos proto a mano. Si tus protos dependen de otros protos, agregas el directorio de dependencia una sola vez.
- JSON de entrada, JSON de salida. Al igual que BloomRPC, Apidog renderiza los mensajes de protobuf como JSON editable, para que no tengas que codificar manualmente cargas binarias. Si necesitas entender ese mapeo, consulta protobuf a JSON.
- TLS, metadatos y autenticación. Alterna grpc:// o grpcs:// por solicitud, y adjunta metadatos y configuración de autenticación para las configuraciones que los servicios reales realmente tienen. Para patrones de token y mTLS, nuestra guía de autenticación gRPC combina bien con esto.
- No es un callejón sin salida. Las llamadas gRPC guardadas (URL del servidor, mensajes, metadatos) se pueden compartir con los compañeros de equipo, y viven en el mismo espacio de trabajo que tus puntos finales REST, escenarios de prueba y documentos publicados. Esa es la parte que ninguna ventana gRPC independiente ofreció jamás.
Cómo se ve el cambio característica por característica
Realizando llamadas
El uso diario resultará familiar. Importar protos, elegir un servicio y método, editar el cuerpo JSON generado, establecer la dirección del servidor, enviar. Las llamadas unarias devuelven un panel de respuesta; las llamadas de streaming abren una sesión donde envías mensajes y observas la línea de tiempo. Los códigos de estado regresan como códigos de estado gRPC, que se leen de manera diferente a HTTP; ten a mano la referencia de códigos de estado gRPC la primera semana.
Streaming, específicamente
Esta es la mejora más notable. El streaming de cliente y bidireccional de BloomRPC eran fuentes comunes de sus problemas abiertos. Apidog documenta los cuatro modos y trata una llamada de streaming como una sesión en vivo en lugar de una solicitud única. Si tus servicios se basan en streams, esa diferencia es la decisión completa; para obtener información sobre los modos en sí, consulta explicación de streaming gRPC.
Reflexión del servidor
BloomRPC requería archivos proto. Apidog también soporta la reflexión del servidor, por lo que puedes apuntar a un servidor habilitado para reflexión y explorar sus servicios sin tener que buscar la revisión de proto correcta. Para revisar rápidamente un servidor de staging que pertenece a otra persona, esto elimina el paso más molesto.
Más allá del cliente
Aquí está el salto de categoría. En BloomRPC, una llamada depurada se evaporaba al cerrar la ventana. En Apidog, los servicios gRPC se encuentran dentro de un proyecto: los compañeros de equipo reutilizan tu configuración de depuración guardada en lugar de reimportar protos y volver a escribir metadatos, y el mismo espacio de trabajo contiene tu trabajo REST y WebSocket, pruebas automatizadas de API gRPC, simulaciones para tus puntos finales HTTP y documentos publicables. La mayoría de los backends gRPC también sirven REST o GraphQL en algún lugar; si estás sopesando esos límites de protocolo, los hemos comparado en REST vs GraphQL vs gRPC y profundizado en las ventajas y desventajas en gRPC vs REST.
BloomRPC vs Apidog de un vistazo
| BloomRPC | Apidog | |
|---|---|---|
| Estado | Archivado en enero de 2023; README: no se recomienda su uso | En desarrollo activo |
| Llamadas unarias | Sí | Sí |
| Streaming de servidor / cliente / bidireccional | Parcial, con problemas conocidos | Todo soportado, estilo sesión con línea de tiempo |
| Importación de Proto | Archivos .proto locales | Archivo local, URL, reflexión del servidor |
| TLS | Básico | Alternancia grpc:// / grpcs:// por solicitud |
| Metadatos y autenticación | Edición de metadatos | Metadatos más configuración de autenticación |
| Compartir en equipo | Ninguno (solo local) | Llamadas guardadas compartidas en el espacio de trabajo del equipo |
| Otros protocolos | Solo gRPC | REST, WebSocket, SSE, GraphQL, gRPC |
| Documentos, pruebas, mocks | Ninguno | Misma plataforma, mismo proyecto |
| Precio | Gratis (abandonado) | Plan gratuito para hasta 4 usuarios |
Migrando desde BloomRPC
La nota honesta sobre la migración: no hay nada que exportar. BloomRPC no guardaba ningún estado portable significativo, lo que hace que abandonarlo sea trivial:
- Reúne tus archivos .proto. Viven en tu repositorio, no en BloomRPC. Eso es todo el "exportar".
- Importa a Apidog. Crea un proyecto, agrega los protos (o su URL), y agrega directorios de dependencia si tus protos importan otros. Los servicios y métodos rpc aparecen como servicios y métodos. O salta los archivos por completo y usa la reflexión del servidor contra un servidor en ejecución.
- Configura la dirección del servidor y TLS. Introduce la URL de destino y elige grpc:// o grpcs://.
- Recrea los metadatos y la autenticación. Vuelve a añadir los encabezados y tokens que habías pegado en BloomRPC, esta vez guardados con la solicitud para que los escribas una sola vez.
- Guarda y comparte. Las llamadas guardadas se convierten en la configuración de depuración compartida del equipo, lo cual es lo primero que notarás que nunca tuviste.
Un usuario de BloomRPC que funcione debería estar enviando llamadas en Apidog en diez minutos, porque los pasos del 1 al 3 son el mismo ritual que ya conoce.
Otras alternativas a BloomRPC que vale la pena conocer
Apidog es la respuesta si quieres gRPC dentro de una plataforma API completa. Si tu necesidad es más limitada, sé justo con las herramientas limitadas:
- grpcurl: curl para gRPC. La herramienta adecuada para scripts de shell, comprobaciones de CI y líneas de comando únicas contra servidores con reflexión habilitada; no es una GUI y no pretende serlo. Lo comparamos en profundidad en la mejor alternativa a grpcurl.
- grpcui: el hermano de grpcurl que sirve una interfaz web temporal para un solo servidor. Bueno para una revisión rápida de cinco minutos, sin estado guardado por diseño.
- Kreya: un cliente de escritorio dedicado para gRPC y REST con un flujo de trabajo de proto pulido y un nivel gratuito; lo más parecido a un sucesor directo de BloomRPC si específicamente quieres un cliente independiente. Consulta qué es Kreya y la mejor alternativa a Kreya para saber dónde se encuentran sus límites.
- Postman: añadió soporte para gRPC en 2022, así que si tu equipo ya lo paga, funciona; se aplican los precios habituales de Postman y las ventajas/desventajas del espacio de trabajo, cubiertas en la mejor alternativa a Postman.
- evans: un REPL de terminal para gRPC con un modo interactivo. Amado por las personas que viven en tmux; un no-iniciador para cualquiera que quisiera la GUI de BloomRPC.
El patrón: CLIs para automatización, GUIs de propósito único para trabajo gRPC aislado, Apidog cuando gRPC es un protocolo entre varios y quieres las llamadas, pruebas y docs en un solo lugar.
Preguntas frecuentes
¿Todavía se mantiene BloomRPC?
No. El repositorio fue archivado el 4 de enero de 2023, y su README indica que ya no se recomienda su uso. No hay actualizaciones, correcciones de seguridad ni lanzamientos próximos. Cualquier comparación actual de clientes gRPC debería excluirlo como opción para nuevas configuraciones.
¿Puedo importar mi configuración de BloomRPC a Apidog?
No hay un archivo de importación porque BloomRPC no almacenaba nada portable. La migración significa reimportar los archivos .proto de tu repositorio (o usar la reflexión del servidor), luego configurar la dirección del servidor, el esquema TLS y los metadatos. Es un trabajo de diez minutos, y después la configuración se guarda y se puede compartir en lugar de estar atrapada en una sola máquina.
¿Apidog soporta streaming gRPC?
Sí, los cuatro tipos de llamadas: unaria, streaming de servidor, streaming de cliente y streaming bidireccional. Las llamadas de streaming se ejecutan como sesiones en vivo donde envías mensajes y observas una línea de tiempo de tráfico. Para un repaso sobre cuándo encaja cada modo, consulta streaming gRPC.
¿Qué pasa si solo necesito llamadas gRPC rápidas desde la línea de comandos?
Usa grpcurl. Maneja bien las llamadas programadas y ad-hoc, especialmente contra servidores con reflexión habilitada, y pertenece a CI independientemente de la GUI que elijas. Nuestra guía de alternativas a grpcurl cubre dónde deja de ser suficiente.
¿Puedo probar APIs gRPC y REST en la misma herramienta?
En Apidog, sí: gRPC, REST, WebSocket, SSE y GraphQL conviven en un solo proyecto, por lo que un servicio que expone tanto gRPC como REST tiene un mismo hogar. Nuestra guía para probar APIs gRPC muestra el flujo de trabajo de principio a fin.
Retira el cliente archivado
BloomRPC te dijo que te fueras; la única pregunta es a dónde. Apunta Apidog a tus archivos .proto o a un servidor con reflexión habilitada, haz tus primeras llamadas unarias y de streaming, y guárdalas junto al resto de tu trabajo API. Descarga Apidog gratis; un equipo de 4 personas no paga nada, y tus protos son el único archivo de migración que necesitas.