[mxstbr]

The ecosystem is rather new, but the folks from Apollo have been doing amazing work. Between graphql-tools, graphql-server and Apollo Client most of the big chunks are done for you. (including very bleeding edge stuff like subscriptions)

The one big unsolved issue right now is Authorization, i.e. how do you handle permissions? (everything else, like authentication, you can handle with the server itself or there's tooling for it)

I'm collaborating with the Apollo folks on some possible solutions, if you're interested read this issue and chime in: https://github.com/apollographql/graphql-tools/issues/313

[andrewingram]

So, been thinking about this one for a couple of years and think it's probably a mistake to make GraphQL responsible for permissioning for anything other than a quick MVP. It's a concern that should pervade your stack rather than being "decloaked" at the outer edges. It's the responsible for your underlying data layer to determine what a user permitting user is allowed to do. Additionally, there are many approaches to permissioning that exist for good reasons, and appearing to bless one approach would feel short-sighted.

I agree that there are reasons you may want GraphQL to handle permissions initially, but much like libraries that map your types to database table, it'll be a solution you walk away from quite early on. It'd feel strange for it to be built into graphql-tools itself, which is concerned with building an executable schema, but I could see it being a relatively useful library that's essentially just a bunch of resolver decorators.