Diseñador visual para APIs Spring Boot: modelás entidades y servicios en un canvas y exportás un proyecto que compila —un servicio único (monolito) o varios que se comunican (microservicios).
apigen genera a partir de un schema, pero decidir cómo se estructura el sistema —qué entidades hay, cómo se agrupan en servicios, qué habla con qué y por qué protocolo— es más fácil de razonar viéndolo que escribiéndolo. apigen Studio es esa capa visual, y funciona igual para un servicio único (monolito) que para varios servicios comunicados (microservicios).
El modelo se arma en un canvas (React Flow con auto-layout de ELK): entidades y servicios como nodos, relaciones y conexiones entre servicios como aristas, con las conexiones síncronas (REST/gRPC) y asíncronas (Kafka/RabbitMQ) dibujadas distinto. Las rutas de gateway y la configuración de mensajería se editan en paneles aparte, no en el canvas. Al exportar, cada servicio se manda al backend de apigen y vuelve compilado; el resultado se empaqueta en un único proyecto multi-servicio.
Desarrollador único. Arrancó el 20 de enero de 2026 — dos días después de que APiGen pivoteara a una plataforma completa de generación de código. Diseñé cada pantalla, escribí cada línea. 440 commits en 18 días activos; el proyecto salió en un sprint corto e intenso.
Tomé bootify.io como referencia. El flujo de generación de una sola app que ofrece es limpio y útil, pero en el momento en que la pregunta pasa a ser "¿cómo se hablan estos tres servicios entre sí?" la herramienta no tiene respuesta. Ese hueco es exactamente donde pasa el trabajo que importa.
Studio se construyó para llenar ese hueco. El modelado de entidades es lo mínimo esperable; el diseñador de microservicios es el punto.
La decisión de producto más determinante. Studio no es un "clon de bootify.io". Suma un diseñador servicio-a-servicio: varios servicios en un canvas, conexiones entre ellos, un diseñador de rutas de gateway para el ruteo HTTP y un diseñador de eventos/mensajes para los flujos asíncronos —ambos en paneles dedicados, separados del canvas—, y una exportación multi-servicio que emite una arquitectura, no un solo proyecto.
Ese es el diferenciador. El editor de entidades es la puerta de entrada que se siente familiar; el diseñador de microservicios es lo que hace que valga la pena usar Studio una vez que un equipo crece más allá de una sola app.
Tradeoff: alcance. Un generador de una sola app es un producto acotado; un diseñador multi-servicio es una superficie mucho más grande. Más features significa más lugares donde romperse, más interacciones que validar, y más decisiones que diseñar. La apuesta es que la profundidad se paga sola en arquitecturas de tres o más servicios.
Cuando hay relaciones entre nodos, Studio usa ELK para un layout de grafo por capas. Cuando no las hay, cae en una ubicación por grilla. El mismo enfoque aplica a los mapas servicio-a-servicio. El layout es parte de la lógica del producto — predecible, determinista, repetible entre importaciones — no una pasada cosmética al final.
Tradeoff: acoplamiento del layout. Cambiar el algoritmo de layout se vuelve un cambio a nivel producto, no un retoque de CSS. La contrapartida es que dos usuarios importando el mismo archivo OpenAPI ven el mismo layout, lo que hace posible la revisión y la colaboración.
Toda la edición, validación y preview corre en el cliente — sin ida y vuelta al backend mientras modelás. Los stores de Zustand manejan las preocupaciones del editor por separado; Zod valida las importaciones y la estructura del proyecto; React Flow maneja el canvas.
La persistencia es la red de seguridad. Autosave a IndexedDB en cada cambio significativo. Historial de snapshots retenido por proyecto para que los usuarios puedan volver atrás. Snapshots de seguridad previos a la importación, así una importación destructiva se puede recuperar si el merge sale mal. El principio: client-heavy está bien mientras no se pueda perder trabajo.
Mantine 8 como framework de UI. Está bien construido y sacó el producto rápido, pero ata el editor a sus convenciones de diseño y sus componentes. Un enfoque más headless (Radix + un design system propio, o MUI con un theming más profundo) me habría dado más libertad para construir patrones específicos de editor — toolbars más densas, manejo del foco más controlado, contenedores de layout que encajen mejor con la edición de grafos.
El README tiene una justificación para Mantine; en retrospectiva el tradeoff fue real. El producto avanzó más rápido al principio y paga un pequeño impuesto ahora cada vez que el editor necesita patrones de UI que pelean con los defaults de Mantine.
Aplicación solo-navegador, sin backend propio:
Hablemos sobre tu próximo proyecto o conocé más sobre mi experiencia.