I was more thinking about my use case without considering all of the possible use cases such as Infrastructure as Code, which this project seems more suited for.
My use case is to create simple explanatory diagrams about a concept / idea rather than a real-world scenario: in those cases, I always end up using Draw.io. This causes me to waste a lot of time dragging and dropping around just to illustrate something simple :(
I guess that with my solution (which btw I'm developing here: [0]), you get a versionable diagram from a YML file that can be parsed and exported everywhere thanks to GraphViz. My idea of the input YML file is the following: [1]. This is a YML representation of the architecture shown in the README.md.
Your JSON/YAML representation doesn't have to be in the go-diagrams module itself. It is just a layer you can build on top of go-diagrams. So I suggest to keep your project independent.
I just forked the project linked on this article, I didn't create the original version myself: my addition to what has been posted here is the idea of parsing a YAML file and getting back the diagram, without having to write a single line of Go code (:
I was more thinking about my use case without considering all of the possible use cases such as Infrastructure as Code, which this project seems more suited for.
My use case is to create simple explanatory diagrams about a concept / idea rather than a real-world scenario: in those cases, I always end up using Draw.io. This causes me to waste a lot of time dragging and dropping around just to illustrate something simple :(
I guess that with my solution (which btw I'm developing here: [0]), you get a versionable diagram from a YML file that can be parsed and exported everywhere thanks to GraphViz. My idea of the input YML file is the following: [1]. This is a YML representation of the architecture shown in the README.md.
[0]: https://github.com/denysvitali/go-diagrams/tree/feature/pars...
[1]: https://github.com/denysvitali/go-diagrams/blob/feature/pars...