Cross-cutting containers?

[azban]

Hi,
I'm looking to overlap containers, rather than requiring containers to be nested.

I was hoping that I could have the "cloud" container intersect the "app" container and have app.server live in the intersection. Is this possible? Is there an alternative that people like?

app: {
  client: {
    shape: image
    icon: https://icons.terrastruct.com/tech/browser-2.svg
  }

  server: {
    icon: https://icons.terrastruct.com/azure/Compute%20Service%20Color/VM/VM-windows.svg
    shape: image
  }

  client -> server
}

cloud: {
  app.server

  database
}

[alixander]

yeah this is not possible in D2 right now. i agree this should be possible. will think on the syntax...

[pleshevskiy]

Maybe I misunderstood you, but maybe you wanted something like this?

app {
  client: {
    shape: image
    icon: https://icons.terrastruct.com/tech/browser-2.svg
  }
}

app.client -> cloud.app.server

cloud: {
  app: {
    server: {
      icon: https://icons.terrastruct.com/azure/Compute%20Service%20Color/VM/VM-windows.svg
      shape: image
    }
  }

  database
}

[azban]

Nope, looking for something like this:

[pleshevskiy]

Oh, very interesting. Haven't seen that before.

[brandondrew]

Isn't the DB a part of the app too?

I realize this is simply an example, and there may be other examples where it makes sense for the "cloud" box to be partially inside and partially outside the "app" box, but in this case I don't see the value of it.

Also the whole idea of the "cloud" in diagrams is that there are lots of details we're ignoring. What is the detail here that is so important to capture?

I hope I don't sound like I'm being difficult. I'm really just trying to understand the use case, and I'd really like to see an example where it makes sense to do this.

[alixander]

What if we allow defining shapes that can specify encompassing other objects.

x.y -> a.b

c: {
  # c would be drawn to be around the bounding box of x.y and a
  constraint: [x.y; a]
}

I think we can reuse the constraint keyword, it's unambiguous and sounds reasonable.

The limitation is that these shapes themselves cannot have any children.

[gavin-ts]

This is a bit of a tangent, but could we make the parent reference ../ instead of _.? I don't remember why _. was selected, was it to avoid conflicts with local files or something? I would think we could distinguish the two given parent ref is used as a key, and files are used as a value

[alixander]

You're proposing changing the syntax for going into a container from . to / for this one use case?

[gavin-ts]

oh right that's why, it would be ../../grandparent going up, but grandparent.parent.child going down

so _._.grandparent is more consistent with grandparent.parent.child (to be clear)

If we did change it, I think it should keep parent.child for downwards and only be ../uncle going upwards, but I see the inconsistency, I think ../ is just seems more natural to me than _.

[arjunrbery]

The ../../grandparent feels intuitive, but the _._.grandparent looks way better in my opinion.

[brandondrew]

../../grandparent follows shell path conventions, where / is the separator and . refers to a current directory and .. refers to a parent, while on the other hand grandparent.parent.child follows the dot-notation of object-oriented programming languages, where . is a separator. Mixing the two together would be very confusing and offer no benefit. Using _ as a parent makes perfect sense to me, even if I don't know of any precedent in some other syntactic system for doing so.

[brandondrew]

I don't find constraint to convey the idea of encompassing other objects without following normal nesting rules. How about this instead:

x.y -> a.b

c: {
  encompass: [x.y; a]
}

[alixander]

TALA does actually have the foundations for this. For example, the code is set up for a "place X in a way that a bounding box between X and Y and Z do not include any other shapes"

[silopolis]

Hi,
Kindly pointed here by @alixander on Discord, I'm joining that thread to share my use case for this: being able to code diagrams like the one below:

Specifically, being able to represent the Auto-Scaling Groups and the DB subnet group that are crossing the availability zones groups.

About the syntax, I believe I could live with only absolute root.path.to.entity refs, allthemore if aliases can be defined when the need to shorten names becomes pressing. But, of course, relative path are surely nice to have and talking about them, contrary to first thought, I prefer the _ notation.

Something like:

AZ1: {
  WebNet: {
	EC2_Web
  }
  AppNet: {
	EC2_App
  }
}

AZ2: {
  WebNet: {
	EC2_Web
  AppNet: {
	EC2_App
  }
}

ASG_Web: {
  AZ1.WebNet.EC2
  AZ2.WebNet.EC2
}

ASG_App: {
  AZ1.AppNet.EC2
  AZ2.AppNet.EC2
}

VPC: {
  AZ1.WebNet
  AZ2.WebNet
  AZ1.AppbNet
  AZ2.AppNet
}

Cloud: {
  AZ1
  AZ2
  VPC
}

On a nth look, the VPC case may be trickier 🤔

Just hope this will eventually be part of the free tier as the subscription is not in my pocket reach...

Thanks for all
TY

[behniafb]

Is there any update on this feature?

[clipstick]

Can this be looked at as a feature, I would use this a lot if Cloud architecture diagrams and so would a lot of my colleagues.

[alixander]

Maybe we introduce a new groups keyword.

groups: {
  aws_things: AWS Objects {
    style.fill: green
  }
}

x: {
  a.group: groups.aws_things
}

y: {
  b.group: groups.aws_things
}

---

Even though there's no way for Dagre or ELK to support this in a way that grouped things are close to each other for a clean box, in theory you can wrap the two nodes in some minimum bounding box or hoop.

Like what if you wanted to group satellites and storage here?

This looks very unclean, but can't think of any other solutions and is maybe good enough.

I guess you'd have to search a path from one corner of top-left-most object to the bottom-right-most that goes through all objects, and then inflate it. Seems very dubious if that can yield good results.

---

Another option is that this is a grid-specific feature.

Since grids is our layout algorithm, it can ensure that nodes end up close to each other. And from what I've seen of these use cases, it looks quite grid-like.

This of course runs a big limitation that it won't work on regular objects in the main layout. Plus if you want to do this between two grids which are in separate containers which go through the main layout algorithm, it still can't do anything about proximity.

[terlar]

Another example is visualization of multi-cluster setups: