Hey all, I have a question regarding Graphql versi...

# graphql-kotlin

[Jared Rieger]

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?

[Dariusz Kuc]

graphql does not support versioning

[Dariusz Kuc]

whole point is that you can introduce new fields without breaking existing clients

[Shane Myrick]

And then mark the existing fields as @Deprecated

https://opensource.expediagroup.com/graphql-kotlin/docs/schema-generator/customizing-schemas/deprecating-schema

[Jared Rieger]

@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.

[Big Chungus]

@Jared Rieger well graphql is exposed via HTTP POST endpoint, so nothing stops you from introducing /graphql/v1 & /graphql/v2

[Big Chungus]

Basically employing rest api versioning strategy for the entire graph

[Jared Rieger]

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?

[Shane Myrick]

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

[Shane Myrick]

You could view the deprecated field usage if you used a schema registry to track down the remaining clients over time