| This looks like a cool project and I like to support developers that share their projects here and on Twitter. Looks great, felt pretty snappy to use. Replace the demo on the home page with a good screen shot of a diagram. It’s a bunch of random interactions so it just looks like a mess of icons and arrows. That said, software diagramming is broken. Pretty icons are great and all, but without common annotations and consistency; what’s the point? I’ve seen so many diagrams, with bidirectional arrows between an EC2 instance and an RDS instance. ec2 <—-> rds Great. The EC2 goes in and out of the RDS instance? Using common annotations like making the arrow from the requestor and having some details of the request goes a long way. ec2 —[r/w public]—> rds Maybe even use the schema and roleARN to give some useful request auth context. Using solid arrows for sync and dashed for async. If both sides of an arrow make requests... don’t use two sided arrows, draw an arrow for each and annotate appropriately. And LucidCharts, Visio, etc? Instant docrot. I’d love to see more diagrams as code, along side the code they represent so diagram changes and code changes can happen in the same PR. PlantUML, mermaid, and mingrammers’s diagrams are great options here. I really like Simon Brown’s C4 modeling [1]. It really helps teach you to diagram systems by focusing on what the system does, not how pretty the diagram is. C4 Builder is also great. [2] [1]: https://c4model.com/ [2]: https://github.com/adrianvlupu/C4-Builder |
My problem is who made the diagram... a developer only sees EC2 connecting to RDS, a network guy sees a two-way data flow.