IDL Part 4: Perspective overrides
This is part 4 of a series of posts on the ilograph diagramming language (IDL). In part 3, we looked at the ilograph resource tree. As discussed there, the resource tree not only helps organize resources, but it enables context nodes in perspectives.
There are multiple perspectives in an ilograph, but only one resource tree, so by default all perspectives will have the same context nodes. We can, however, override this on a per-perspective basis using perspective overrides.
To explore this, let’s start with the same ilograph that we used in part 3, presented here in its entirety:
resources: - name: WonderApp Users subtitle: End users color: navy style: plural - name: AWS subtitle: Cloud service provider children: - name: Tech Company Account subtitle: AWS Account children: - name: WonderApp VPC subtitle: Virtual Private Cloud children: - name: Alpha subtitle: EC2 Instance color: peru - name: Bravo subtitle: EC2 Instance color: peru - name: Load Balancer subtitle: Application Load Balancer color: green - name: WonderApp Store subtitle: S3 Bucket color: red perspectives: - name: WonderApp color: navy defaultRelationLabel: Requests relations: - from: WonderApp Users to: Load Balancer - from: Load Balancer to: Alpha, Bravo - from: Alpha, Bravo to: WonderApp Store
As you can see, this ilograph has a handful of resources and a single perspective called WonderApp. When rendered, it looks like the perspective pictured at the top of this post.
So far, this ilograph presents how data requests flow through a simple AWS system. If we wanted to add information about the security groups in this system, we could do so by adding two new resources and a small new perspective:
resources: ... - name: AWS subtitle: Cloud service provider children: - name: Tech Company Account subtitle: AWS Account children: - name: WonderApp VPC subtitle: Virtual Private Cloud children: ... - name: LB Security Group subtitle: Security Group color: purple - name: Instance Security Group subtitle: Security Group color: purple perspectives: ... - name: Security color: purple defaultRelationLabel: Part of relations: - from: Alpha, Bravo to: Instance Security Group - from: Load Balancer to: LB Security Group
This new perspective, called Security, tells us which VPC resources belong to which security group. When rendered, it looks like so:
While this new perspective is valuable, we might instead want to show the security groups in our original perspective (WonderApp, the one at the top of this post showing request flow). We could accomplish this by changing the resource tree and making the Alpha, Bravo and Load Balancer resources children of their respective Security Group resources. Modifying the resource tree, however, is not always possible or desireable.
Instead, lets modify the original perspective (WonderApp) by giving it two overrides:
perspectives: - name: WonderApp color: navy defaultRelationLabel: Requests relations: ... overrides: - resourceId: Load Balancer parentId: LB Security Group - resourceId: Alpha, Bravo parentId: Instance Security Group
These two overrides tell the perspective to use different parents for the specified resources. When rendered, this perspective now has new context nodes:
In this newly modified perspective, the instances and the Load Balancer resources are now implicitly a part of their respective security groups. The Security perspective, meanwhile, calls this out explicitly. We can switch between the Security and WonderApp perspectives to see the difference:
We can take this further. Let’s add resources for the AWS regions and availability zones so that we can use them in perspectives:
resources: - name: AWS subtitle: Cloud service provider children: ... - name: us-east-1 subtitle: Region color: green children: - name: AZ1 subtitle: Availability Zone color: darkgreen style: dashed # draw as a dashed box - name: AZ2 subtitle: Availability Zone color: darkgreen style: dashed # draw as a dashed box
These resources (us-east-1, AZ1 and AZ2) fall completely outside of the Tech Company Account branch of the resource tree (as is true to life). Like before, we can make a simple new perspective showing that the Alpha and Bravo EC2 instances run in AZ1 and AZ2, respectively:
perspectives: ... - name: Availability Zone color: green defaultRelationLabel: Runs in relations: - from: Alpha to: AZ1 - from: Bravo to: AZ2
Now, what if we want to show the region and availability zones as context nodes for the WonderApp perspective? Instead of modifying WonderApp, let’s create a new perspective, called Region that has the same relations as WonderApp, but different overrides:
perspectives: - name: Region color: peru defaultRelationLabel: Requests relations: # same as WonderApp overrides: - resourceId: WonderApp VPC, WonderApp Store parentId: us-east-1 - resourceId: AZ1, AZ2 parentId: WonderApp VPC - resourceId: Alpha parentId: AZ1 - resourceId: Bravo parentId: AZ2
When rendered, this perspective looks exactly like the WonderApp perspective, only with different context nodes:
In a future post, we’ll look at some more advanced scenarios. In the meantime, you can check out this example ilograph (and its source) in the ilograph app. And as always, you can reach me at firstname.lastname@example.org or @ilographs on twitter with questions or comments.