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:

Fix over-caching with dynamic IO caching in Next.js 15

Next.js 15 caching overhaul: Fix overcaching with Dynamic IO and the use cache directive.

David Omotayo
Aug 6, 2025 ⋅ 10 min read
LLMs are facing a QA crisis here’s how we could solve it

LLMs are facing a QA crisis: Here’s how we could solve it

LLM QA isn’t just a tooling gap — it’s a fundamental shift in how we think about software reliability.

Rosario De Chiara
Aug 4, 2025 ⋅ 7 min read

Windsurf vs. Cursor: When to choose the challenger

Windsurf AI brings agentic coding and terminal control right into your IDE. We compare it to Cursor, explore its features, and build a real frontend project.

Chizaram Ken
Jul 31, 2025 ⋅ 9 min read

The CSS if() function: Conditional styling will never be the same

The CSS Working Group has approved the if() function for development, a feature that promises to bring true conditional styling directly to our stylesheets.

Ikeh Akinyemi
Jul 30, 2025 ⋅ 12 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