A visual designer for Spring Boot APIs and microservices — model entities, gateway routes, and event flows, then export a multi-service project.
Tools like bootify.io let you design a single Spring Boot app visually — entities, relations, basic CRUD, auth. That solves one piece of the work. It does not solve modeling a microservices architecture: multiple services, the routes between them, the events that flow between them, and the export of all of that as a coherent system.
I wanted a visual designer that handled the system, not just the app. One canvas where I model services, draw connections, configure a gateway, lay out event/message flows, and export the whole thing as a multi-service project ready to feed APiGen.
Studio is a browser-based visual designer for Spring Boot APIs and microservices. Model entities and relations like in bootify.io, then go further: add multiple services, wire gateway routes, design event/message flows, validate cross-service compatibility, and export the full architecture as a project that APiGen can generate. Import SQL schemas or OpenAPI contracts, edit them visually with conflict-aware merge, and never lose work — IndexedDB autosave plus snapshot history are built in.
Single developer. Started January 20, 2026 — two days after APiGen pivoted into a full code generation platform. Designed every screen, wrote every line. 440 commits in 18 active days; the project shipped in a short, intense sprint.
I took bootify.io as the reference. The single-app generation flow it offers is clean and useful, but the moment the question becomes "how do these three services talk to each other?" the tool has no answer. That gap is exactly where the work that matters happens.
Studio was built to fill that gap. The entity modeling is the table stakes; the microservices designer is the point.
The most consequential product decision. Studio is not "bootify.io clone". It adds a service-to-service designer: multiple services on one canvas, connections between them, a gateway route designer for HTTP routing, an event/message designer for async flows, and a multi-service export that emits an architecture, not a single project.
That is the differentiator. The entity editor is the entry point that feels familiar; the microservices designer is what makes Studio worth using once a team grows past one app.
Tradeoff: scope. A single-app generator is a tractable product; a multi-service designer is much larger surface area. More features means more places to break, more interactions to validate, and more decisions to design. The bet is that the depth pays back on architectures with three or more services.
When there are relations between nodes, Studio uses ELK for layered graph layout. When there are not, it falls back to grid placement. The same approach applies to service-to-service maps. Layout is part of the product logic — predictable, deterministic, repeatable across imports — not a cosmetic pass at the end.
Tradeoff: layout coupling. Changing the layout algorithm becomes a product-level change, not a CSS tweak. The upside is that two users importing the same OpenAPI file see the same layout, which makes review and collaboration possible.
All editing, validation, and preview runs in the client — no backend round-trip while modeling. Zustand stores manage editor concerns separately; Zod validates imports and project structure; React Flow drives the canvas.
Persistence is the safety net. Autosave to IndexedDB on every meaningful change. Snapshot history retained per project so users can roll back. Pre-import safety snapshots so a destructive import can be recovered if the merge goes wrong. The principle: client-heavy is fine when no work can be lost.
Mantine 8 as the UI framework. It is well-built and shipped the product fast, but it ties the editor to its design conventions and components. A more headless approach (Radix + a custom design system, or MUI with deeper theming) would have given more freedom to build editor-specific patterns — denser toolbars, more controlled focus management, layout containers that match graph editing better.
The README has a justification for Mantine; in retrospect the tradeoff was real. The product moved faster early on and pays a bit of a tax now whenever the editor needs UI patterns that fight Mantine's defaults.
Browser-only application, no custom backend:
Hablemos sobre tu próximo proyecto o conoce más sobre mi experiencia.