4 ms·
> There are plenty of things that a client is not supposed to see, often based on the roles of the requesting user. That means that you can't pass a GraphQL que
by friedman23 10y ago
> There are plenty of things that a client is not supposed to see, often based on the roles of the requesting user. That means that you can't pass a GraphQL query directly to an underlying DB provider without verifying what is being requested. You'd end up writing about the same amount of code that you'd have written with a standard REST-style interface.
Why would you need to write the same amount of code? The only code that would remain the same is the validation logic.
- untog 10y agoPerhaps another way of asking it: how is GraphQL different to sending SQL statements from the client? In both scenarios you'd be "only" handling validation logic and ignoring the rest.
- tscs37 10y agoNot much difference except that GraphQL does not specify how the data is processed. You could answer the data out of a flatfile for all that the endpoint cares. It also allows to secure access against arbitrary data requests, since on the server end, the resources only see the individual requests to the DB. In my experience, it's much easier and less verbose to validate GraphQL after parsing than just validating any SQL you plan to pass to the backend.
- jordanthoms 10y agoThe amount of code needed to verify that only the proper fields and records are included for a particular response taking into account the user's permissions etc is often not so different from the code needed to retrieve just that data in the first place. There is an issue here where as you give more sophisticated querying capabilities to the client, you need to have correspondingly more sophisticated validation of those queries on the server, which offsets some of the gain.