Attributes vs Required (opinionated) Struct

[talentedmrjones]

Cue, and tooling built around Cue using the Go API, provides a couple ways to reliably find necessary values:

1. The tools can require a specific structure with known fields OR
2. The tools can look to known attributes thereby supporting arbitrary structures

In stax, a CLI tool for managing CloudFormation stacks in Cue, it is currently supporting a specific struct in order to find values necessary to deploying a stack. While the directory structure is highly flexible, the collection of stacks themselves is fairly rigid:

#Stack: {
  Profile: string                                  // maps to AWS profile and related credentials
  Region: "us-east-1" | "us-east-2" // truncated example
  Template: {                                     // converted to YAML and provided to CloudFormation
    Resources: [string]: {}
    Outputs?: [string]: {}
  }
}

Stacks: [string]: #Stack // stax explicitly looks for the top level Stacks field

So far this works really well, at least for a code base that conforms to the above. At the company where stax was conceived and forged in the fires of production, it was used daily by a team of 10 SREs and very efficiently managed 600 stacks across 20 accounts. But as an open source tool intended to serve every team while not imposing its own opinions, I wonder if this struct may in some context be limiting.

An alternate approach is to use attributes, which some teams such as dagger.io and grafana are doing with their respective tools.

Attributes if used could look like this:

myCollectionOfCloudyThings: {
  GcpStuffs: {},
  AwsStuffs: {
    theseThingysGoCloudFormation: {
      "prod-rds": {
        Prof: string @stacks(profile) 
        Reg: string @stacks(region)
      } @stax(stack)
    }
  }, // use @stax() and or @dagger() throughout
  Grafana: {} // use @polly()
}

It also seems possible to meet in the middle:

myCollectionOfCloudyThings: {
  GcpStuffs: {},
  AwsStuffs: {
    theseThingysGoCloudFormation: {
      "prod-rds": #Stack & {...} @stax(stack) // this struct must conform to a schema as defined above
    } // @stax(stacks)
  }, // use @stax() and or @dagger() throughout
  Grafana: {} // use @polly()
}

The benefit to is that the code base can be tuned to fit exactly what a team is trying to accomplish considering all the tools in their pipeline and that a single Cue code base could be used by multiple tools. The downside to supporting attributes, and not enforcing a common struct is that the tool may suffer from the lack of consistent use throughout its community.

What do you think of attributes vs an enforced known struct? Beyond merely solving this specific issue with stax, I'd like to see the community settle on an idiom for similar scenarios.

[jlongtine]

My sense is that the "meet in the middle" strategy is important. Unifying with #Stack helps by enforcing schema and giving nice error messages for misspellings, or invalid values/configuration. That said, it might still be useful to allow or use @stax attributes in some cases...

I believe Dagger is doing something more like the "meet in the middle" strategy.

I agree that having the community settle on some idiom would be useful. I've seen questions like this pop up on a number of occasions.