ChilliCream / graphql-platform

Welcome to the home of the Hot Chocolate GraphQL server for .NET, the Strawberry Shake GraphQL client for .NET and Banana Cake Pop the awesome Monaco based GraphQL IDE.
https://chillicream.com
MIT License
5.17k stars 737 forks source link

Generating predictable model classes in strawberry shake #6873

Open jarlef opened 7 months ago

jarlef commented 7 months ago

Product

Strawberry Shake

Is your feature request related to a problem?

A recent issue ive encounter is that the generated client in Strawberry Shake is not consistent when using fragments

E.g the following graphl queries agains a schema.

fragment MySchool on School {
    id
    name
}

fragment MyStudent on Student {
    id
    name
    age
    school {
        ...MySchool
    }
}

query GetStudentById($id: Int!) {
    student(id: $id) {
        ...MyStudent
    }

}

query GetStudents {
    students {
        ...MyStudent
    }
}

In this case it will generate two models for student. GetStudentById_Student and GetStudents_Students_Student both inherting from their own dedicated interfaces that in turn inherits from IMyStudent. But deeply nested properties like the School property on GetStudents_Students_Student and GetStudentById_Student gets randomly assigned a type that is either IGetStudents_Students_Student_School or IGetStudentById_Student_School.

The solution you'd like

Since they are both implementing the fragment interface IMyStudent it clearly means the school property can only be of one type and IMO that should be IMySchool which is the fragments interface. One could also argu that student and students properties should also use the interface IMyStudent instead of their own interfaces since the fragment is an intent to express a named contract.


Link to minimal reproduction from #7194: https://github.com/pm7y/StrawberryShakeBugRepro

dillon-miller2-carvana commented 6 months ago

This is causing us a huge headache anytime we need to update the schema. We have several queries and mutations that we call that share common fragments. Due to this, whenever we update the schema, there is a high likelihood that the randomly assigned type that Strawberry Shake uses to generate the classes which utilize fragments will change as well.

ryanhill-mastery commented 3 weeks ago

Are there any updates to this? Or workarounds in the meantime? This is a pretty major issue that results in some developers being able to compile our applications and some who cannot. It also results in our build pipeline "randomly" failing.

michaelstaib commented 3 weeks ago

No, focus for version 14 is mainly Hot Chocolate with minor fixes to Strawberry Shake. For 15 we have some time budget for Strawberry Shake, so once 14 is shipped we will go over sb issues and reprioritize some for the 15 backlog.