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 billy@ilograph.com or @ilographs on twitter with questions or comments.