We recently shipped Solarch, a deterministic diagram-to-code compiler. Currently, the rules engine outputs strictly to NestJS. The core compilation logic is stable, and our next phase is focused on embedding this engine deeper into standard developer workflows.
Before we lock in the engineering cycles for the upcoming updates, I want to gather raw feedback from developers who build and maintain complex backend architectures.
Here is the immediate roadmap we are planning:
VS Code Extension: Full bi-directional synchronization between the visual architecture nodes and your local codebase.
MCP & API Support: Model Context Protocol integration to allow external AI agents and tools to interact directly with the Solarch rules engine.
Expanded Topology: Introduction of new node relation rules and support for different architectural diagram frameworks.
Obsidian-Style Graph Charts: A macro-level, interconnected dependency graph to visualize and navigate massive, complex systems.
Solarch
Saw the VS Code extension on the roadmap with bi-directional sync. That's the part I'd want to understand better. If I generate a service, then add custom logic in the generated file, and later go back to edit the node in Solarch, does the sync know to preserve what I wrote? Or does it treat the generated file as owned by the engine and overwrite everything?
Separate question on node types. The built-in set right now is tables, DTOs, services. If I need something the rules engine doesn't have a template for, like a queue consumer or a scheduled job, can I define that as a custom node type, or is the vocabulary locked to what ships with the platform?
Solarch
@whetlan Really great questions.
To be completely transparent: Right now, Solarch is strictly one-way and export-based. So yes, if you write custom logic in the generated file and then re-export from the canvas, it will currently overwrite your code.
But fixing this is our absolute top priority. We are shipping the VS Code extension within the next month. It will use a Git-based sync to recognize your custom logic and smartly merge any new architectural updates without touching your hand-written code. You will keep full control over your business logic.
As for custom nodes: Currently, the node types are locked to our built-in ones. This strictness is what allows us to guarantee that the generated NestJS code compiles perfectly without any errors. However, letting you define your own custom nodes (like queue consumers or cron jobs) is definitely on the roadmap once we nail the bi-directional sync.
Thanks for the feedback, this is exactly the kind of discussion I was hoping for today!🖖
Nice! I've been using a fork of mermaid.js in the past to generate visualizations ad-hoc. Excited to give this a try!
Solarch
@andreas_rubin_schwarz Thank you for your feedback!