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:

Understanding Security In React Native Applications

Understanding security in React Native applications

Explore the various security threats facing React Native mobile applications and how to mitigate them.

Wisdom Ekpotu
Mar 27, 2024 ⋅ 10 min read
Warp Adoption Guide: Overview, Examples, And Alternatives

warp adoption guide: Overview, examples, and alternatives

The warp web framework for Rust offers many enticing features. Let’s see when and why you should consider using warp in your projects.

Ukeje Goodness
Mar 26, 2024 ⋅ 8 min read
Integrating Next Js And Signalr For Enhanced Real Time Web App Capabilities

Integrating Next.js and SignalR to build real-time web apps

In this tutorial, you’ll learn how to integrate Next.js and SignalR to build an enhanced real-time web application.

Clara Ekekenta
Mar 25, 2024 ⋅ 8 min read
Exploring Tailwind Oxide

Exploring Tailwind Oxide

Tailwind Oxide was introduced to address common issues that exist with Tailwind CSS, such as the complex setup process.

Marie Starck
Mar 22, 2024 ⋅ 5 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