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.
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.
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)
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.
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.