[2022-08-04] Redefine the problem that "struct" is solving

[benjie]

Lee: Wrapping this up. Advice: Back up from proposal to redefine the problem. For input unions that was very helpful. A lot to like, but also opening up a lot of things we decided against. Sounds a bit like a panacea. We might solve all problems, but in an inadequate way.

🎥 Timestamped YouTube link

• assignee(s): @benjie
• source: https://github.com/graphql/graphql-wg/blob/main/notes/2022/2022-08-04.md#:~:text=Lee%3A%20Wrapping%20this%20up.%20Advice%3A%20Back%20up%20from%20proposal%20to%20redefine%20the%20problem.%20For%20input%20unions%20that%20was%20very%20helpful.%20A%20lot%20to%20like%2C%20but%20also%20opening%20up%20a%20lot%20of%20things%20we%20decided%20against.%20Sounds%20a%20bit%20like%20a%20panacea.%20We%20might%20solve%20all%20problems%2C%20but%20in%20an%20inadequate%20way.

---

Note: Action Item issues are reviewed and closed during Working Group
meetings.

[leebyron]

Related to the Metadata discussion on 9/1 - may expand on this in the future

[benjie]

Update from last night's WG: we still need to collect more use cases, but "structured leaves" is definitely a problem that needs solving one way or another.

[benjie]

As agreed at the October 2023 WG; action items that have been inactive for more than 6 months can be closed.

[benjie]

I still feel that struct does a great job of solving the "structured symmetric data" problem (e.g. as a replacement for JSON scalar, because you can pull it down, modify it, and then send is straight up again without having to worry about the addition of new fields causing breakage). It also felt like a great solution for the other problems I laid out in the RFC... I might write a fresh RFC for it at some point that addresses just the "structured symmetric data" problem. I still think solving the various other issues has value though.

[benjie]

Another example of someone having a problem that fits well into what struct offers: graphql/graphql-spec#929 (comment)

[holomekc]

Hi @benjie ,
we also face the same issues. Our workaround is also a JSON scalar, so basically serialized json string in our response. We do not really like it and would love to see the struct rfc becoming a reality. I could find some discussions in different issues regarding this issue, but it seems that this one is the latest one where you wrote something. What is the current status of this feature?

[benjie]

Please share more details of your use case; the issue at the WG was that strict solved too many problems and may not have been the best solution for any of them, so we need to have some concrete full use cases that we can then find solutions for, which may include struct as an option. Maybe you could start by explaining how JSON scalar is insufficient for your needs?

[holomekc]

I cannot share company internal information, but I can map and simplify it to something else. I hope it helps:

type Thing {
  name: String!
}

type SpecialThing implement Thing {
  name: String!
  additionalValue: String!
}

type RecursionIssueThing implements Thing {
  name: String!
  things: [Thing]
}

type Agent {
  id: String!
  things: [Thing]
}

type AgentMetaData {
  id: String!
}

type Query {
  agents: [AgentMetaData]
  agent(id: String!): Agent
}

The issue is our RecursionIssueThing, because it uses the interface Thing again. When we try to query the data we cannot define a fragment, which creates a cycle.

Our Agent can have Things, which are defined by a different system. It is totally unclear how the Things are structured. We have 7 similar types to SpecialThing and 1 additional type similar to RecursionIssueThing. In this case our gui always requires all information. So a query like this sounds great, but is sadly currently not possible:

query {
  agent(id: "1") {
    id
    things
  }
}

Defining the complete structure is already for one level kind of difficult. So your struct concept sounded great, because we could handle Things like a leaf.

Instead, at the moment we defined a scalar Any, which serializes the information from above to a string. So we loose the type safetly. It is more like a hidden secret now, how the Things are structured.

Edit: We also generate the queries and response types, which typically remove the need to write the models by hand.