Native interfaces + IDs 🧵

[astral imp]

Proposal: https://gist.github.com/vito/158619f941f529244dda00b0d45a8a1c
PR: https://github.com/dagger/dagger/pull/12041

[astral imp]

I'm treating this like a secondary track unless others think it's worth being my primary focus. I ended up down this path while dogfooding Workspace + LLM patterns, with the hope to clean up Env.

Goals:

• no more dynamic schema fields like Foo.asBar, Env.withFooBind
  • I believe this could have SDK implications, like finally having a single cacheable dagger.gen.go
• eliminate loadFooFromID in favor of "standard" node(id: ID!): Node
• interfaces are actual GraphQL interfaces, rather than objects with interface semantics implemented by Core

cc @mortal socket @near copper I think this came up in SF, related to your per-module codegen - interfaces and Env were blockers for an optimization we were talking about because of dynamic fields

cc @fleet dome in case this could tie in to any of your design schemes (e.g. interfaces in core)

[astral imp]

@sterile steppe Humbly requesting another repo: github.com/dagger/querybuilder. Similar situation as otel-go - I need to make changes to querybuilder for interface support (inline fragments: ... on { ... }) but need codegen to point to a new dependency, since dagger.io/dagger/querybuilder won't have it until we ship (chicken/egg problem). This should be the last repo from that situation, figured we'd need it eventually when we did otel-go.

[fleet dome]

Done 🙂

[mortal socket]

Quick question regarding that, I saw in the codegen that we are not using this dependency and still point to dagger.io/dagger/querybuilder.
Is there a particular reason?

In order to pull core bindings from dagger.io/dagger instead of generating them, we need to match the bindings with the module version that we try to execute.
But that means everything else (querybuilder/telemetry) must be decoupled.

Good thing is that we already decoupled telemetry and you also did querybuilder so can I use it on my PR?