Leonardo Losoviz
Apr 15, 2020 ⋅ 9 min read

Versioning fields in GraphQL

Leonardo Losoviz Freelance developer and writer, with an ongoing quest to integrate innovative paradigms into existing PHP frameworks, and unify all of them into a single mental model.

Recent posts:

Using Rust And Leptos To Build Beautiful Declarative User Interfaces

Using Rust and Leptos to build beautiful, declarative UIs

Leptos is an amazing Rust web frontend framework that makes it easier to build scalable, performant apps with beautiful, declarative UIs.

Eze Sunday
Nov 30, 2023 ⋅ 10 min read
5 Best JavaScript Multi-Dimensional Array Libraries

5 best JavaScript multidimensional array libraries

Learn more about the 5 best JavaScript libraries for dealing with multidimensional arrays, such as ndarray, math.js, and NumJs.

Pascal Akunne
Nov 30, 2023 ⋅ 4 min read
Dom Scandinaro Leader Spotlight

Leader Spotlight: Leading by experience with Dom Scandinaro

We spoke with Dom about his approach to balancing innovation with handling tech debt and to learn how he stays current with technology.

Jessica Srinivas
Nov 30, 2023 ⋅ 6 min read
Vite Adoption Guide Overview Examples And Alternatives

Vite adoption guide: Overview, examples, and alternatives

Vite is a versatile, fast, lightweight build tool with an exceptional DX. Let’s explore when and why you should adopt Vite in your projects.

David Omotayo
Nov 29, 2023 ⋅ 16 min read
View all posts

2 Replies to "Versioning fields in GraphQL"

  1. Unfortunately, this solution will not work when changing field type or removing mandatory constraint. Any suggestions on that front?

  2. If we want to rename/remove a field. I think @deprecated is enough and simple. I think this solution might be more suitable for add/remove required from a field. If we make versionConstraint mandatory, won’t the query statement becomes verbose?
    I think using version will not avoid the “field cemetery” issue. Using deprecated we have 1 field cemetery. Using version we might have several field cemetery with different versions which is better than deprecated. Because we can have a gray strategy to retired those fields. What if we have a date or release date in deprecationReason like “deprecationReason: at 9/10 release”? so that we can know which one is older.
    The idea of using extension to tell the engineer of warning and deprecated fields is really great! Though I don’t agree with all the opinions of this post, this is still an awesome post!!

Leave a Reply