[tormeh]

Note that this means the back end team has to keep the schema backwards compatible forever. Having everyone have direct access to the schema (speaking from SQL experience) is bad. This is the start of a slow moving disaster train that you can't stop.

[alexchamberlain]

I disagree; the GraphQL schema should be your point of stability, whereby anything in front or behind can change. That being said, ofc, you'll need to deprecate something at some point and that is fine, it might just take a couple of weeks. See @deprecated decorator examples

[tomnipotent]

> the GraphQL schema should be your point of stability, whereby anything in front or behind can change

This is the bit of abstraction I see most developers fail to understand when evaluating GraphQL.

[RussianCow]

Not forever, just as long as you support out-of-date clients (either because of cached JS on the web, or mobile apps that haven't been updated recently). Plus, you generally don't want to introduce backwards-incompatible changes to your schema anyway at a certain scale, unless you can afford to have planned downtime, so GraphQL doesn't add anything new here.

[BerislavLopac]

I'm not quite sure what does the database schemas have to do with the front-end queries...

[elliotec]

In this case OP is talking about the GraphQL schemas, not the DB.

[BerislavLopac]

I'm not sure which OP do you mean? The parent mentions "SQL experience", the grandparent is ambiguous, and the GGP explicitly mentions "database schema".

If by OP you mean the original article, I completely agree with you; my comment was directed to its ancestors.