Expand all option

[murph-cat]

Feature name Expand all items on diagram.

Is your feature request related to a problem? Please describe. As an example, I am interested in a complete expansion of all IAM information, and we have hundreds of policies and roles. It is absolutely absurd to expect me to have to right click every policy, role, user, group, etc. to map those connections. An option to expand all items on the diagram is the only thing that would make this feasible. There are a non-0 number of circumstances where that would need to be clicked multiple times until the chart ceased to populate any more data. I can also see a circumstance where someone might want to only keep expanding out on particular item types without wanting to hide that type altogether.

Describe the feature you'd like to see implemented The same way you can right click in the field and see "Collapse all" and "Remove all," I want to see "Expand all" that runs "Expand" on every item in the diagram.

Describe the value this feature will add to AWS Perspective Honestly right now I'm not sure how anyone is using Perspective for projects that are anything but tiny. It's even a burden to expand out just the stack and substacks of the CloudFormation resource that generated Perspective, with all the right clicking on individual items.

Describe alternatives you've considered Hiring a Mechanical Turk to do all the right clicking for me.

[thebutler12]

Thanks for raising this feature request. We are very keen to hear about how users would like to interact with and build architecture diagrams using Perspective.

We have a couple of ideas:

1. As you suggested, enable an Expand all option. This would let the user expand everything that exists in the architecture diagram. The concern here is that the architecture diagram could get very busy, very quickly.
2. Enable Multi-selection of resources in the architecture diagram and add an Expand option. This would let the user expand a selection of resources with a single click.
3. Enable Expand resource type option that will let the user quickly expand all resources of a certain type.
4. Introduce a Relationship level configuration that the user can increase/decrease and it will update the graph queries to return that level of relationships from the graph. Instead of only getting resources that are directly related to the one selected, the user will be able to control how deep the graph queries go when fetching related resources. An example would be the user sets the Relationship level to 2 and selects a Lambda function to display. It will immediately display Lambda function -> Environment variables -> Database Instances, removing the need to expand Environment variables manually to fetch the next level of relationships.

We'd be happy to hear any other suggestions around this topic as we try to understand how users are interacting with Perspective.

[pandew]

I've got the same feedback Murph has. Let go of the whole resource type thing, that's not a good a paradigm. The value of your tool is the "arrows" and costs of resources, not the count of how many lambdas I have or that each lambda is $2.378345678 / month.

I like the concept of relationship level, from a network connectivity and cost perspective.

Why am I using the tool, what relationships am I looking for? The important relationships/things to me threats, cost, and performance.

[murph-cat]

To respond to your points, Matt:

1. I suppose I am not a designer, but I expect the image to get very busy quickly. I think most architectures are complicated and that's part of what this tool reveals.
2. That sounds like a great way to scope it down, great point.
3. I think there's a general point here that the things that get expanded are not consistent between resource types, so to disambiguate, I think it would make sense to say expand $relationship_type for $resource_type, and in general to make all that clearer.
4. This sounds good but is the same as my point above. So for example, since I mostly care about IAM and network relationships, I don't care about environment variables, it's weird to me that's a step in between.

[pandew]

I'm ok with busy, its a like a skyscraper architecture, lots of pages with different views. Color coding the arrows with network flow direction , red means its on direct path to a resource open to the internet, yellow means its on an indirect path, and green its got no way to get out. Where cost could be the thickness of the arrows, so if a resource is top 10% of costs touches another one the arrow is the thickest?

[rakshb]

We've evaluated this request and added this to our backlog but it is not prioritized in the immediate roadmap for the solution.