It works by automatically changing CSS classes, and it looks like the underlying isoflow library should support this.
show comments
gtirloni
This looks amazing. I find Mermaid.js ugly and the syntax difficult/buggy but unfortunately it's one of the best supported diagram tools in static site generators. It'd be awesome to have Isoflow diagrams embedded in Markdown like that.
show comments
pjbk
I always loved the isometric diagrams on Clive Maxfield's [1] books about electronics. Since a lot of circuits are non-planar (flip flops, semiconductor layers, FPGA architecture), adding a perspective view makes things uncluttered, and easier to understand and remember. I think it translates well to many technologies.
If you care, Snowflake launched a product called Openflow less than a month ago. Yours will probably be very difficult to discover.
show comments
knorker
It's a bit confusing to see "openflow" diagrams that include network components, that have nothing to do with OpenFlow. https://en.wikipedia.org/wiki/OpenFlow
It is unrelated, right? Just a name clash with an overlapping domain?
show comments
x0z
I've not done anything special here, just wrapped the community edition of ISOFLOW https://github.com/markmanx/isoflow
and made it dead easy to set up and run.
You can now export and load JSON backups of your diagrams allowing you to essentially have as many as you want, which the community version of ISOFLOW restricts. Enjoy!
show comments
Valodim
So if this can be hosted as a github page, why not make the "quick start" section a link to just use the PWA?
donatj
I am unclear exactly, what is this doing on top of Isoflow? Seems like Isoflow is doing a lot of the heavy lifting here?
show comments
martypitt
Diagrams look great - well done.
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.
If this could be hosted on GH pages, is there any demo link?
show comments
[deleted]
h1fra
NB: it's using isoflow
fnord77
I'm inclined to agree with Edward Tufte - the 3D part doesn't add any information to the diagrams, so it is superfluous
show comments
zero0529
Can you export to other formats than JSON?
show comments
tankenmate
FYI, they changed their name to FOSSFlow about an hour ago.
show comments
Yesman85
If it can consume terraform state and visualize it, that would be amazing.
show comments
wooptoo
There's also diagrams.mingrammer.com which is a fantastic tool.
progx
Node version? Could not get it running with 22 or 24 on linux.
show comments
jayde2767
Pretty cool app, OP. Thanks for sharing the details.
ram_rattle
Looks dope, Thanks for doing this
9dev
This is a little tangential, but I've wondered for a while if there's a better way to visualise the composition of software systems.
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 :)
show comments
careful_ai
Kudos—OpenFLOW feels like reclaiming infrastructure from CLI sprawl. Low-code network management with observability baked in is a powerful combo. The secret sauce is that it keeps humans in the loop: scripting flows is easy, but visualizing and validating them in real-time makes it production-ready. That human-checkpoint mindset is where dynamic tooling meets trust.
b0a04gl
what if we can make these diagrams synchronized with reality. you need the diagram to pull from the same source of truth as your actual infrastructure - whether that's terraform state, kubernetes manifests, or service discovery. that way diagrams become less historical artifacts and more of living documentation
show comments
dr_kretyn
"beautiful" here is definitely subjective. I only see a diagram and it looks like from PowerPoint presentation from the marketing team to the sales team.
Why JS world frequently uses "beautiful" or "modern" to describe its project? Often that hides something else.
This is awesome. I built a lightweight home status server called Stylus that would probably pair very well with this:
https://github.com/mmastrac/stylus
It works by automatically changing CSS classes, and it looks like the underlying isoflow library should support this.
This looks amazing. I find Mermaid.js ugly and the syntax difficult/buggy but unfortunately it's one of the best supported diagram tools in static site generators. It'd be awesome to have Isoflow diagrams embedded in Markdown like that.
I always loved the isometric diagrams on Clive Maxfield's [1] books about electronics. Since a lot of circuits are non-planar (flip flops, semiconductor layers, FPGA architecture), adding a perspective view makes things uncluttered, and easier to understand and remember. I think it translates well to many technologies.
[1] https://www.clivemaxfield.com
If you care, Snowflake launched a product called Openflow less than a month ago. Yours will probably be very difficult to discover.
It's a bit confusing to see "openflow" diagrams that include network components, that have nothing to do with OpenFlow. https://en.wikipedia.org/wiki/OpenFlow
It is unrelated, right? Just a name clash with an overlapping domain?
I've not done anything special here, just wrapped the community edition of ISOFLOW https://github.com/markmanx/isoflow and made it dead easy to set up and run. You can now export and load JSON backups of your diagrams allowing you to essentially have as many as you want, which the community version of ISOFLOW restricts. Enjoy!
So if this can be hosted as a github page, why not make the "quick start" section a link to just use the PWA?
I am unclear exactly, what is this doing on top of Isoflow? Seems like Isoflow is doing a lot of the heavy lifting here?
Diagrams look great - well done.
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
If this could be hosted on GH pages, is there any demo link?
NB: it's using isoflow
I'm inclined to agree with Edward Tufte - the 3D part doesn't add any information to the diagrams, so it is superfluous
Can you export to other formats than JSON?
FYI, they changed their name to FOSSFlow about an hour ago.
If it can consume terraform state and visualize it, that would be amazing.
There's also diagrams.mingrammer.com which is a fantastic tool.
Node version? Could not get it running with 22 or 24 on linux.
Pretty cool app, OP. Thanks for sharing the details.
Looks dope, Thanks for doing this
This is a little tangential, but I've wondered for a while if there's a better way to visualise the composition of software systems.
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 :)
Kudos—OpenFLOW feels like reclaiming infrastructure from CLI sprawl. Low-code network management with observability baked in is a powerful combo. The secret sauce is that it keeps humans in the loop: scripting flows is easy, but visualizing and validating them in real-time makes it production-ready. That human-checkpoint mindset is where dynamic tooling meets trust.
what if we can make these diagrams synchronized with reality. you need the diagram to pull from the same source of truth as your actual infrastructure - whether that's terraform state, kubernetes manifests, or service discovery. that way diagrams become less historical artifacts and more of living documentation
"beautiful" here is definitely subjective. I only see a diagram and it looks like from PowerPoint presentation from the marketing team to the sales team.
Why JS world frequently uses "beautiful" or "modern" to describe its project? Often that hides something else.