Heh.
If you want to realize those advantages, you will end up introducing a "simple" solution like GraphQL. In an insecure environment.
Read, man. Don't just react.
If you want to realize those advantages, you will end up introducing a "simple" solution like GraphQL. In an insecure environment.
Read, man. Don't just react.
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.
No, no it is not in the spec, as of February 15th, 2016:
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.
> For each node type and edge type in the graph, you provide a required canSee() function which controls its visibility.
> It doesn't belong in the spec
_kek_
Am I on candid camera?
permission
authorization
authentication
role
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)
You can return null if someone requests an object they're not allowed to access, or return an error, or whatever it is that you're currently doing.
I've been playing around with GraphQL, and my approach has just been to include a permissions object for the actions a user can take on the resource:
{ permissions: { destroy: false, update: true, ... } }
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).
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