Client side logic and rendering has a HUGE number of advantages when done correctly. Most sites don't but it is possible. API Churn is simple to solve (graphql, mvvm pattern, or as a proxy api wrapper can all be used quite effectively to solve it) and if you build an universal (meaning progressive enhancement enabled) application you can pick up the advantages of a SPA without losing the very limited advantages that a true server rendered app gives you.
I think you misunderstand what GraphQL is. It's not direct access to the database. It is a view model abstraction on top of your database which includes permissions checks for each node and edge, so in many ways it's actually more secure than the alternative of securing each endpoint adhoc.
GraphQL is a copy of OData / IQueryable which is over 5yrs old. Its not new. Just like flux, is EventSourcing rebadged.
If u search about these technologies, which are quite old, u can find the positive and negative consequences of their implementations in the wild.
ie. exposing IQueryable<T> is an anti-pattern and security vulnerability. As soon as your API is public, and you try and lock it down from simple DoS attacks, your not going to end up at the beginning. The only place these technoligies belong would be in your trusted environment - API <=> DataSource, not Client <=> API
I understand what GraphQL is: it's a step towards full datastore access on the client side. It exposes some security issues (what if you don't want a user to have access to some data and miss a security constraint, as you will, and they modify your GraphQL language to see it?) but it isn't the full security clusterfuck.
Yet.
Again, the tradeoff is touching your API (or security model) every time UX needs change, or exposing more and more security issues client side.
That's absolutely not true. For each node type and edge type in the graph, you provide a required canSee() function which controls its visibility. This granular access control leads to a more secure system than the alternative, which is doing access control at the endpoint level and then hoping that the endpoint doesn't fetch data it isn't supposed to.
Update: I think Peter Hunt is talking about Facebook's internal server-side implementation of GraphQL. That's the only way his comments make any sense given what's publicly available.
It doesn't belong in the spec, it belongs in the implementation. But yes, the reference implementation (graphql-js) should probably be updated to demonstrate access control.
You SHOULD be checking permissions on each node and edge, but the details are entirely in your hands.
I agree 100%.
However, that's not what the GP said above, which was "It is a view model abstraction on top of your database which includes permissions checks for each node and edge, so in many ways it's actually more secure than the alternative of securing each endpoint adhoc.". I contest the use of "includes permissions checks" and "actually more secure" for a system that does not at any point specify any type of security at all. It's just as secure as any random REST API or route (in other words, as secure as you make it, and not any more).
See below: I think Peter Hunt is talking about Facebook's internal (or maybe public?) server-side implementation of GraphQL. That's the only way his comments make any sense given what's publicly available.
That's certainly possible, but it cuts against his argument which is that "It is a view model abstraction on top of your database which includes permissions checks for each node and edge".
That's maybe what FB's internal vision of GraphQL is, but that's not what we have available out here in non-FB land. If carsongross's argument is that GraphQL is moving the database to the client side, and all of the security issues that go with it, then a rebuttal that says 'Nope, GraphQL is more secure' isn't going to cut water if the only specification of security is locked away. Particularly since people may be accidentally throwing their GraphQL client side not realizing that there are security issues involved at all (since Peter Hunt says it's more secure for example)
