It's not versionless per se, but given you ask for the specific fields you want (e.g. user { name }), you don't have to be anal about bumping the version every time a new prop is added to a response, such as in REST, e.g. GET /users/1234

However, if you change the data schema around, like `user` is now `person` or something, or a mutation call changes the required params, there's no magic, you either update the clients, or add versioning.

And if not clear GraphQL is not "SQL on the web", so just because your DB schema changes, your GraphQL API doesn't have to change (basically like REST)

This is a very important point.

I'd argue all these "publish your DB schema as a GraphQL endpoint" frameworks that seem to proliferate have done a lot of damage to GraphQL's reputation. Strongly coupling data to presentation seems like such an obvious anti pattern, yet tools doing just that seem to be very popular for some reason.

Agreed, the reason I really like GraphQL is you can map different parts of your schema "tree" to different backend systems, APIs, etc. This makes your API plane/BFF nicely decoupled from those details like DB tables, etc.

To be fair, you don’t have this problem with REST either (any new properties can be safely ignored). Where it breaks down however (and this applies more to GraphQL because of its insistence of not being versioned) is when you want to deprecate some fields that a lot of clients depend on.

I agree with you, though I have worked with a lot of folks who insist new fields are worthy of a new version. I mostly use Javascript which is really forgiving, but sometimes people have these C++/etc client libraries that blow up with unexpected data apparently.

If you want to make a breaking change, yeah - you need to version it. No question. It's fairly flexible in how much you can change without it being breaking, but it's not magic.

Beyond that it's arguably "versionless" because it does nothing to address the problem. Which is essentially fine, and is what most protocols do: you make a completely new API or change the endpoint (e.g. http path) to gradually make breaking changes (expose both, migrate callers whenever), because something like that is basically always an option.