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:

Stagehand and Gemini logos on a gradient background symbolizing AI web automation

How to build a web-based AI agent with Stagehand and Gemini

This guide walks you through creating a web UI for an AI agent that browses, clicks, and extracts info from websites powered by Stagehand and Gemini.

Elijah Asaolu
Jul 4, 2025 ⋅ 8 min read
Getting Started With Claude 4 API: A Developer's Walkthrough

Getting started with Claude 4 API: A developer’s walkthrough

This guide explores how to use Anthropic’s Claude 4 models, including Opus 4 and Sonnet 4, to build AI-powered applications.

Andrew Baisden
Jul 3, 2025 ⋅ 16 min read
ai dev tool power rankings

AI dev tool power rankings & comparison [July 2025 edition]

Which AI frontend dev tool reigns supreme in July 2025? Check out our power rankings and use our interactive comparison tool to find out.

Chizaram Ken
Jul 2, 2025 ⋅ 3 min read
how API client automation can save you hours in development

How API client automation can save you hours in development

Learn how OpenAPI can automate API client generation to save time, reduce bugs, and streamline how your frontend app talks to backend APIs.

Lewis Cianci
Jul 1, 2025 ⋅ 7 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