Diagram Maker: Open sourcing IoT visualization
aws.amazon.com
aws.amazon.com
In addition to basic stuff like zooming and moving nodes GoJS has undo management, data binding, templates, lots of built in tools and layouts and a large showcase of customizations of each, animations, palettes, overviews, etc. It's not free, but if you're looking to use a library to buy developer time, I think it's a much better deal than this offering.
(for us, Go stands for Graph Object)
I agree gojs is confusing as it seems to be "go-lang implementation in javascript" but I believe no one can claim the ownership over the word "go", as it's an normal English word as well...
About five years ago I built something similar but with a single focus of building interactive network diagrams.
We would link individual nodes to backed APIs that would get triggered by certain network events and cause the nodes to animate (e.g. traffic flow, ACL rule hit etc). We would bind buttons on the diagram to send requests to external APIs to trigger requests etc. We also had things like packet counters and traffic flow diagrams on the canvas that would show additional detail.
We also repurposed it later to visually build networks of VMs: we would lay out the nodes and networks on the diagram, configure OS, network address settings etc and then hit a button to convert the diagram to an Ansible playbook that would make it all real.
That was a really fun project - I should dig out that code and play with Terraform some time. :)
My use case is complicated as I'm playing in someone elses sandbox with constrained JS and DOM API's (that's what Salesforce calls it when they liberate you of software).
Does anyone know if there is a python equivalent?
See more details here: https://awslabs.github.io/diagram-maker/why/features.html#da....
Hopefully this will get traction and they will start to build in some of this intelligence and perspectives into the application (presumably as a plugin).
Think of, for example, Apache NiFi [1] but instead of the components being constrained to a single JVM execution, the components are realized as AWS or Azure services. That "operational view" of your architecture would be super neat, especially when statistics about each component can be visualized in real time.
Yet lots of people have been doing it, successfully, for decades with pen and paper (equivalent). I think you need to constrain your use case from "all architectures" to whatever it is you are trying to describe.
Say you're diagraming the architecture of the aforementioned app and you have your VPCs and your ELBs and compute and subnets and IGW and tidy little boxes containing them all to indicate this is everything in prod AWS account, us-west-1. Then you need to add an S3 bucket and dynamo db table. Most people would just drop a bucket icon outside of the VPC and label it...maybe dynamodb sits inside the region box and s3 kind of straddles it. Good enough conceptually to talk through the design.
Now imagine you want to automate the process of generating that view (or the associated resource graph) automatically. That's where it gets tricky. Tons of service-specific rules start to come into play. Kind of a mess.
And those are just static relations. For interactions and data flows, you need sequence diagrams.
I wrote about this last month: https://blog.ilograph.com/posts/fixing-aws-architecure-diagr...
- Continue to spin out products to support common business use cases.
- Expose commonly used functionality from products via this WYSIWYG tool.
- Allow drag and drop programming by connecting services.
- Lambdas are the primary way that a business bridges gaps between OOB functionality and business requirements, but are still connected up via this WYSWYG tool once created.
It would be a while before it was useful to FAANG, but maybe mom and pop businesses could cheaply partner with AWS experts to ship custom software?
I'm comparing this to Node-RED [0] which is pretty robust and has a large ecosystem. Ultimately, I think the value in diagramming platforms is not just in the software, but the community around it that creates plugins/extensions for different use-cases.
Your point about Gantt carts may be right for you, but for our simple timelines it's good. The real winner for me was the state diagrams. Thanks!
It's my go-to tool whenever I need to document something visually, whenever I have a meeting with my peers and I want to get them quickly up to speed with the process I have in mind, I just create a quick sequence diagram and we can hit the ground running.
[0] https://plantuml.com/state-diagram [1] https://www.planttext.com/
There is also the desire to have documents have more types of pictures/ drawings. A Swiss Army knife of drawing tools. In our case it's ok if some of the styles are not as powerful.
Thanks for the link!
Does this mean that Step Functions and CloudFormation will adopt this library? Both already have similar visualizations.
[0] https://github.com/uber/react-digraph [1] https://github.com/wbkd/react-flow
If PowerPoint works for you, that's great! I have no problem with it. But it doesn't work for me. There is a true need in this area for better diagramming tools. Plantuml and graphviz were good ideas, for which we still lack a killer execution/implementation.
I use a mac and am not a big fan of opening up office products for simple/quick things
Some of the reasons why an application developer might prefer using Diagram Maker over using draw.io's embed mode in their application: * You want to customize the editor to match your application's styling. * You want the editor to impose your application's custom semantics, for example: your application doesn't allow cycles.