4 ms·

Very nice, but IMHO this should be the engine behind a file that could easily be parsed such as YML / JSON. I really don't see the point in having to write a G

Very nice, but IMHO this should be the engine behind a file that could easily be parsed such as YML / JSON. 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. I guess I'll try to do what I just described because I feel like this could have a lot of potential for my system diagrams

mongol 6y ago
But with Go you get a schema of sorts. And also, you can easier programmatically generate "dynamic diagrams". For example by letting it parse a YAML file :-)
baq 6y ago
yaml is a serialization format. You need at least a schema at which point you might as well write in a nicer language.
- ThePhysicist 6y ago
  I agree with OP on this, YAML seems better suited for such a tool as you can easily add some form validation to it and then serialize it into Go data structures. You really shouldn't have to recompile your codebase in order to modify a diagram.
  - baq 6y ago
    You don’t recompile the codebase, you build the diagram. You can build it with a tool that converts yaml into svg or golang into svg. The point is that there isn’t much difference as the diagram build process has the exact same high level steps in either case.
liversage 6y ago
> 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.
delusional 6y ago
Writing my masters thesis, where i worked a lot with TikZ, the real power came from being able to defined your own graphing primitives. With that you can defined your own graphing system. Maybe you have a type of arrow that means something UML doesn't have, just define that class and then defined how it will look. Maybe you have a connection type that requires separate arrows in both directions, just defined the syntax. You can make all these things happen with regular TikZ, but the ability to define macros and classes makes for easier graph drawing, and a unified definition. It also means you can distribute these styles and let others work on your graph language.
IshKebab 6y ago
Given that this uses Graphviz, you may as well just write you diagram using that if you want something declarative.
- denysvitali 6y ago
  Without the added value of good quality PNGs that you'll have to add yourself (:

mongol 6y ago

But with Go you get a schema of sorts. And also, you can easier programmatically generate "dynamic diagrams". For example by letting it parse a YAML file :-)

baq 6y ago

yaml is a serialization format. You need at least a schema at which point you might as well write in a nicer language.

ThePhysicist 6y ago
I agree with OP on this, YAML seems better suited for such a tool as you can easily add some form validation to it and then serialize it into Go data structures. You really shouldn't have to recompile your codebase in order to modify a diagram.
- baq 6y ago
  You don’t recompile the codebase, you build the diagram. You can build it with a tool that converts yaml into svg or golang into svg. The point is that there isn’t much difference as the diagram build process has the exact same high level steps in either case.

liversage 6y ago

> 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.

delusional 6y ago

Writing my masters thesis, where i worked a lot with TikZ, the real power came from being able to defined your own graphing primitives. With that you can defined your own graphing system. Maybe you have a type of arrow that means something UML doesn't have, just define that class and then defined how it will look. Maybe you have a connection type that requires separate arrows in both directions, just defined the syntax. You can make all these things happen with regular TikZ, but the ability to define macros and classes makes for easier graph drawing, and a unified definition. It also means you can distribute these styles and let others work on your graph language.

IshKebab 6y ago

Given that this uses Graphviz, you may as well just write you diagram using that if you want something declarative.

denysvitali 6y ago
Without the added value of good quality PNGs that you'll have to add yourself (: