2020-04-15
2706
#graphql
Leonardo Losoviz
17085
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:

Exploring The Magic Of Runes In Svelte 5

Exploring the magic of runes in Svelte 5

See how to use Svelte 5’s new runes system to declare reactive states and compare them to the existing approach to reactivity in Svelte 4.

Yashodhan Joshi
Jul 11, 2024 ⋅ 7 min read
Building UIs With Franken UI, A Shadcn Alternative

Building UIs with Franken UI, a Shadcn alternative

Explore Franken UI, an open source library of pre-built UI components that takes inspiration from Shadcn UI’s design principles.

Jude Miracle
Jul 10, 2024 ⋅ 11 min read
Working With The Angular Tree: Flat Vs Nested Trees And More

Working with the Angular tree: Flat vs. nested trees and more

The Angular tree view can be hard to get right, but once you understand it, it can be quite a powerful visual representation.

Lewis Cianci
Jul 9, 2024 ⋅ 20 min read
The Top Headless Ecommerce Solutions For Frontend Dev

The top headless ecommerce solutions for frontend dev

Explore the top headless commerce platforms tailored for frontend ecommerce development, with free and paid options like Saleor and Shopify.

Fimber Elemuwa
Jul 9, 2024 ⋅ 6 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