In the world where LLM's are very good at mermaid diagrams is the syntax even that terribly important?
https://github.com/mmastrac/stylus
It works by automatically changing CSS classes, and it looks like the underlying isoflow library should support this.
"You mean FRR?" https://frrouting.org/
(yes, svg within base64 within markdown)
They did.
Reminds me of a similar project years ago that was doing the same thing - they ultimately struggled with monetization and folded (I forget the name) -- however this one is MIT OSS, so I'm guessing that's not a key concern right now.
Note that your "Built with the Isoflow library" link at the bottom to isoflow 404's to https://github.com/isoflow/isoflow
No plans at all for money making, just want people to enjoy using it.
Thank you for pointing out the link, I'll get on that ;)
this way i could tell the LLM that will be generating my JSON to include the following links as X and create the output JSON immediately
^ ISOFLOW have an online demo you can use :)
It is unrelated, right? Just a name clash with an overlapping domain?
Often, there's not only a single way to look at one: There's a user interaction flow through components, but those components also consist of hardware; the hardware might be virtual and composed of several, spread, sub-components, or even containers. You can go down this path pretty deep, and arrive at several different representations of the system that are either impossible to visualise at the same time, or make it incomprehensible.
Ideally, I would want to have a way to document different facets of the system individually, but linked to each other, and be able to change my perspective at anytime. This would allow to flip between UX, network traffic, firewall boundaries, program flow, logical RPC flow, and so on; all while being able to view connected components for a given component at anytime. For example, inspecting an application, then viewing its network ports, then its runtime container, the hypervisor the container runs on, the cloud provider that sits in, and so on.
My idea so far is a graph database that contains all components and the edges between them. The tool would have to be as extensible as possible, so using something like HCL to describe the graph would be great, with extensions for all kinds of components and edges. And finally a viewer to render visual representations of one or more composable layers to flick through, and export etc.
I never got around to working on it yet, but if anyone else had the same idea, I'd be open to collaborating :)
defining diagrams as multiple layers like so
x -> y
layers: {
inside_x: {
a -> b
}
}
Does that make sense?
a.class: backend
b.class: frontend
# hide everything
**: suspend
layers: {
backend: {
# show backend stuff
**: unsuspend {
&class: backend
}
}
}
[1]: https://www.cloudcraft.co/
[2]: I’m part of the Cloudcraft team at DataDog, so obviously, I’m biased.
Why JS world frequently uses "beautiful" or "modern" to describe its project? Often that hides something else.