3 ms·
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
by tormeh 8y ago
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.
- RussianCow 8y agoNot 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.
- alexchamberlain 8y agoI 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 8y ago> 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.
- BerislavLopac 8y agoI'm not quite sure what does the database schemas have to do with the front-end queries...
- elliotec 8y agoIn this case OP is talking about the GraphQL schemas, not the DB.
- BerislavLopac 8y agoI'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.