s0l0ist

I'm working on a python library for Vizdom to be released later this year, but in the mean time, you can use this python library which uses Graphviz under the hood.

- https://diagrams.mingrammer.com/

Hey that's me! Thanks for mentioning it.

So far it has automatic layout that will position (and create a rendering) for hierarchical graphs - even if your data isn't hierarchical in nature. This is how the algorithm works internally as it is a reflection of Dagrejs.

I plan to support more layout types in the future.

As for placement of 'root' nodes (aka source and sink nodes) - in reference to the parent comment - my hope is to expose graph theory methods that you can run before layout/render which would help facilitate this automatically, but it's non-trivial to codify as it requires a substantial refactor to the layout algorithm(s).

Cool I’ll put this on my roadmap

Yeah not really competition as I see it. If you create graphs rarely or need to craft one manually then there are better tools out there.

Maybe my landing page is terrible, but you don’t need an account to download the npm package and start doing things locally.

That being said, I’m more interested in helping individuals who want to programmatically generate graphs - hundred+ updates to them per day, similar to how an APM/telemetry libs work. You instrument once and get the benefits of a real-time graph.

Thank you for pointing this out - it was an error. I actually even forgot to credit the dependencies the binary was built from!

However, that is now resolved. The latest distribution has license mentions for:

- Dagrejs

- NotoSans Font

- *Others (an html file generated via `cargo about` that list all deps used in the final dist)

That being said, I did want to point out that I did take significant influence from Dagrejs which is why you see that the layouts produced look very similar - it is a rough translation into rust. There are changes to some DFS traversals, other optimizations that are rust-specific, and countless bug fixes. I actually spent a lot of time attempting to reproduce the layouts that Dagre generates, but there are some examples that do not produce the same results. At this point, I think it is close enough and would rather spend time writing a new set of algos for better edge crossing minimization and cluster support.

Also, if you're using python today, take a look at https://diagrams.mingrammer.com/

It's pretty good - uses Graphviz under the hood, but supports many cloud icons/logos. Not completely sure if it allows you to provide any icon, but it wouldn't surprise me.

Yeah that and http://magjac.com/graphviz-visual-editor/ are decent. But they will crash on medium/large graphs because the WebAssembly build of Graphviz that they use under the hood isn't compiled to allow memory growth.

If you're already happy with Graphviz wrappers, then the only real benefit is that you can sync the graph to a Vizdom account so you don't have to build anything to view the diagram somewhere outside of local development - it saves you from needing to save the positioned graph to a file to view it (then delete it) or coming up with a way to serve the SVG.

Not to mention the act of performing layout (obtaining positioning data) is relatively expensive for non-trivial graphs. When syncing to a Vizdom account, your application doesn't need to spend cycles to position/render anything. Instead, your graph is positioned and rendered in the dashboard in your browser upon loading (technically, it is also rendered on the server due to my global SSR config).

Also a few of the JS wrappers don't come with a build of Graphviz that allows memory growth, so for somewhat medium/large graphs, the WebAssembly panics. For all other wrappers, it works just fine I'd assume - mainly an issue with not passing the correct build args to Emscripten.

Thank you! Custom icons - not yet. I’ve been mulling over how to do it on server and client that isn’t hacky and that plays nice with edge intersections (how edges will point to the bounding box of the icon/logos)

It’s definitely something I want to support.

Yeah I’ll admit, that isn’t clear. I used DOT to test it a while back and opened that up for folks who also wanted to mess with DOT, but that isn’t the value prop today.

You can create and render as many graphs as you like with the package offline - only the real-time sync is limited.

You know what? You’re right! That’s confusing. I’ll try and make it better.

Really good feedback and I’m being serious. Wish I saw that earlier.

Definitely!

Yes exactly!

Tradeoffs are real. My example displays a few more knobs and yes, it’s more verbose.

I’d say my premise isn’t that “DSLs are bad”, but more along the lines of if a DSL isn’t what you’re looking for, I may have something for you. Particularly if you need your application to generate a view of a graph _during runtime_ so that it is your real-time source of truth.

I find that DSLs and “as code” solutions for several products have their own niche. Take for example Terraform vs Pulumi.

Ah yeah while I do have a live editor for playing with DOT, it’s not a graphviz replacement nor is it primarily what Vizdom is all about. I actually launched a tech preview earlier this year and those two pages were all I really had.

I also wanted to give a shoutout to Greg who built the amazing Leptos rust framework that powers everything.

Read more here: https://leptos.dev/

Neat product! I like the interactivity.

For me (and my narrow use-case), I just couldn’t find a simple tool to sync my graph to somewhere that I could view it easily - especially after I’ve instrumented my application and deployed to the cloud.

Ah yeah, it’s been bugging me as well lol.

I definitely need to update that at some point.

Thanks! Love your product! I didn’t mean to say you don’t have it. I’ll edit my other post.

I’d say for the majority use-case (as I see it), they’re excellent for manual diagram curation. Especially, D2 for software arch diagrams. Mermaid is great at many things.

It’s kind of hard to write up a fair comparison - it’s apples to oranges.

I can say that vizdom performs very fast hierarchical layouts (currently the only supported type). Example 14 in the live editor runs in about 1 second on my M1 Mac - but if you refresh the page it CloudFront will complain since the graph state is all in the URL and it’s too long.

I wrote some functionality to parse DOT to feed it into the layout engine before I got everything working. It was a great way to validate more complex graphs with a DSL that is already prevalent. So for now it’s only present in the webapp.

DOT parsing isn’t part of the npm package, but I’m not totally opposed to include it! It may add 1-2Mb more to the wasm bundle.

Sure! It’s Apache 2.0 licensed, but yes the binary wasm blob is what does all the work and is closed source for the time being.

It’s about 25k lines of rust code compiled to do the following:

- Layout/position a directed graph

- Compute a bounding box for text labels and produce font glyphs for the rendering engine

- Generate an SVG

- Optionally, sync to a Vizdom account

Fun fact, the majority of that wasm blob is what is powering the web application itself. You can see it in action using the editor view/diff on the site.

The npm package is free to use, but closed source until I have bandwidth.

To be clear, you don’t need an account to use the npm package which has all of the functionality to perform layout and rendering. An account is only needed if you want to sync the graph and have a web page to view renderings. This is useful if you’ve instrumented a long lived application with Vizdom, but don’t want to produce a local layout/rendered image because you can’t really “view” it if the service is running in the cloud.

I’m the author, I just got tired of using a DSL and wanted a way to programmatically write/build a graph and quickly see the rendering.

DLS-based diagramming tools like Terrastruct, mermaid, or graphviz definitely have their perks and are very well established for manual graph curation. But I found the lack of programmatic tooling (except terrastruct) a bit of a pain point.