That said, versioning of a graphql api has been done at scale before. Shopify has done it, using versioning in the URL, specifically their admin data api, using month-year release dates as the versions [2]
In reality, of course API versioning is needed.
The "prevailing wisdom" is people who like the tool, don't like its limitations, and want to pretend it isn't a problem.
.
> That said, versioning of a graphql api has been done at scale before. Shopify has done it
Perl people will happily point out that object systems exist for Perl.
Having it not be a standard, uniform part of the core tool is a severe limitation. Shopify needed this rudimentary feature, and tried to give it away because others need it to, and the tool vendors aren't willing (or able) to deliver.
I’d recommend not picking a technology that is versionless by design if you think you’re going to need it. Also I’d dispute that versioning is needed as a rule.
I mean, I don't pick GraphQL, and this is just one small part of why.
Every place that I've ever worked that's attempted to adopt GraphQL has rapidly given it up.
.
> Also I’d dispute that versioning is needed as a rule.
The IEEE once measured peoples' expectations regarding how necessary versioning was, and got a response of something on the order of 40%. There was an uproar, and a whole bunch of people on both sides of the topic tried to call bullshit.
Some middle manager somewhere sent in a letter that said approximately "how about you write a follow-up article where you bin the responses by years of experience?"
The rest of the story writes itself.