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!🖖
The "diagrams and code always in sync" idea resonates hard — I spend my days in financial models where the same drift problem kills you: the logic and the documentation diverge and nobody trusts the output. Keeping the visual map and the underlying mechanics locked together is the whole game. It's the same principle behind ModeLoop (https://modeloop.net/), where the structure of a model has to stay legible as it grows. Nice execution — how are you handling versioning when the code changes faster than the diagram?
Solarch
@samir_asadov
The entropy in financial models is the exact same problem as architectural drift in software. If the map doesn't match the territory, the system becomes a liability. I completely agree with the principle behind ModeLoop—structure must remain legible.
To answer your question directly: right now in v1, we enforce the diagram as the absolute source of truth. It is a strict one-way compiler. If a developer manually changes the generated boilerplate faster than the diagram, the next export will overwrite it.
However, we are fundamentally solving this in our upcoming VS Code extension (shipping in a few weeks). Instead of treating the generated file as 100% owned by the engine, we are implementing AST (Abstract Syntax Tree) parsing and a Git-based control flow.
This allows the engine to recognize manually injected custom logic blocks, perform a smart diff, and merge visual architectural updates without crushing the developer's manual code.
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!