https://kotlinlang.org logo
Title
j

Jared Rieger

12/14/2021, 12:31 PM
Hey all, I have a question regarding Graphql versioning for fields. Does the library support this? Is there something that already exists that should be used instead?
👀 1
d

Dariusz Kuc

12/14/2021, 2:07 PM
graphql does not support versioning
😞 1
whole point is that you can introduce new fields without breaking existing clients
s

Shane Myrick

12/14/2021, 5:16 PM
j

Jared Rieger

12/15/2021, 12:28 PM
@Dariusz Kuc and @Shane Myrick I see. However, in my case I need to change a field from non null to nullable. I guess following your teams suggestion I would have to have something like
@Deprecated("use  username_<something>")
val username: String
val username_<something>: String?
to effectively replace the username field? kinda annoying for clients as there could be multiple fields all meaning the same thing.
b

Big Chungus

12/15/2021, 12:34 PM
@Jared Rieger well graphql is exposed via HTTP POST endpoint, so nothing stops you from introducing
/graphql/v1
&
/graphql/v2
Basically employing rest api versioning strategy for the entire graph
j

Jared Rieger

12/15/2021, 12:47 PM
offt yeah that doesn't sound like fun. Would it be better to rather have separate view models for different clients rather than one large super model?
s

Shane Myrick

12/15/2021, 4:27 PM
I would actually not have separate models. If the username might be null then all clients need to handle that so they should all use the same field. If there is a reason or use case when the username field is never null and different times when it is you can make that a different type to make it more clear. I would avoid doing separate http endpoints unless you are truly exposing a different schema, in which case maybe it should be it's own service
You could view the deprecated field usage if you used a schema registry to track down the remaining clients over time