3 ms·

> I really don't see the point in having to write a Go snippet to describe the architecture: in the end you're providing only data as an input. Writing a progr

> I really don't see the point in having to write a Go snippet to describe the architecture: in the end you're providing only data as an input. Writing a program to generate the diagram is similar to writing a program to generate your infrastructure which is exactly what you do in "infrastructure as code". If your infrastructure is simple then you may not need infrastructure as code. The same can be said for diagrams but at some point you might want the flexibility if the "diagram as code" approach.

denysvitali 6y ago
It all depends on the context, you're right. 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/parse-yml https://github.com/denysvitali/go-diagrams/tree/feature/pars... [1]: https://github.com/denysvitali/go-diagrams/blob/feature/parse-yml/test/assets/parse/ymls/1.yml https://github.com/denysvitali/go-diagrams/blob/feature/pars...
- tomcam 6y ago
  Congratulations on a neat project!
  - denysvitali 6y ago
    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 (:
- dolmen 6y ago
  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.

denysvitali 6y ago

It all depends on the context, you're right. 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/parse-yml https://github.com/denysvitali/go-diagrams/tree/feature/pars... [1]: https://github.com/denysvitali/go-diagrams/blob/feature/parse-yml/test/assets/parse/ymls/1.yml https://github.com/denysvitali/go-diagrams/blob/feature/pars...

tomcam 6y ago
Congratulations on a neat project!
- denysvitali 6y ago
  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 (:
dolmen 6y ago
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.