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.
Interactive diagrams feel like they could become the shared source of truth between humans and agents.
Do users mostly treat diagrams as documentation, or are they becoming active planning tools that drive implementation?
Solarch
@zaid_mallik1
You just saw the exact endgame.
Historically, diagrams are just dead pictures that rot within a week. It's a broken loop. We’re turning the canvas into a literal compiler.
And you are 100% right about AI agents. If humans and AI are going to build complex systems together, they need a strict, deterministic visual language—otherwise, it's just pure hallucination. This is exactly why integrating MCP is our next move. Solarch isn't just a devtool; we are building the interface where human architects and AI agents will collaborate in real-time.
@fatalerrorist The idea of diagrams becoming executable rather than descriptive is what stood out to me as well.
We're building something in the AI workflow space and keep running into the same challenge — humans and agents need a shared representation that both sides can reason about reliably.
Excited to see how far you can push the "canvas as compiler" concept. We're planning to launch soon ourselves and it's always encouraging to see other builders tackling similar coordination problems.
Kudos for the concept.
Just wondering, will you guys support for the FE framework like Angular, NextJS?
Or it will purely BE side ?
I'm leaning to use this ones, if I can create a relationship canvas, showing how FE is consuming the BE services
Solarch
@quan_nhat_minh_hoang
Appreciate the feedback.
To answer your question directly: yes, we are absolutely moving beyond just the backend. We actually already have component and frontend nodes built into our underlying architecture.
The roadmap for this is not just generating isolated UI code, but creating a broader, interactive canvas. You will be able to draw wireframes, establish frontend connections, and explicitly map how those UI components consume your existing backend services.
The exact relationship canvas you are looking for—showing the complete end-to-end flow from the frontend down to the backend nodes—is exactly what we are building next. It will be a unified visual workspace.
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!