3 ms·

Except that the backwards compatible point is nonsense and actually a PRO REST argument. If your database schema changes (or the orchestrated microservices), i

Except that the backwards compatible point is nonsense and actually a PRO REST argument. If your database schema changes (or the orchestrated microservices), i.e. a field in a table gets dropped (lets say new security policies make this field not readable to everyone) you have NO way of making that change without breaking your GraphQL queries. Because you cannot update that queries that are stored on your users Apps, you will end up having more and more hacks in your GraphQL Server to account for all possible query combinations that are out in the wild. And because you have to account for those hacks, you will need to maintain a list of all old and deprecated queries that exist(ed) in your frontend code and make it available to the backend devs, that maintain the hacks in the GraphQL server adapter. With REST, you would have to do the same hacks of course to maintain backwards compatibility - but as the REST Endpoint (and the queries they represent) reside in the backend and are not updated or removed, it is way easier to keep track of the hacks to maintain compatibility.

hn_throwaway_99 8y ago
This is absolutely not correct, but it is a common misunderstanding I've seen with how people use GraphQL. I've posted this before, but I despise how GraphQL has "QL" in the name, so folks think it is similar to SQL in that you should expose your database tables as-is with GraphQL queries. You should absolutely not do this. You should design your GraphQL contracts to closely match the views displayed in your UIs - it even says this in the GraphQL spec: "Product‐centric: GraphQL is unapologetically driven by the requirements of views and the front‐end engineers that write them. GraphQL starts with their way of thinking and requirements and builds the language and runtime necessary to enable that." If your GraphQL types closely hew to the design of your views, it shouldn't matter how you store them under the covers, and clients should have no need to know any details about the underlying storage schema.

hn_throwaway_99 8y ago

This is absolutely not correct, but it is a common misunderstanding I've seen with how people use GraphQL. I've posted this before, but I despise how GraphQL has "QL" in the name, so folks think it is similar to SQL in that you should expose your database tables as-is with GraphQL queries. You should absolutely not do this. You should design your GraphQL contracts to closely match the views displayed in your UIs - it even says this in the GraphQL spec: "Product‐centric: GraphQL is unapologetically driven by the requirements of views and the front‐end engineers that write them. GraphQL starts with their way of thinking and requirements and builds the language and runtime necessary to enable that." If your GraphQL types closely hew to the design of your views, it shouldn't matter how you store them under the covers, and clients should have no need to know any details about the underlying storage schema.