[jayd16]

>GraphQL doesn't fundamentally change the fact that something needs to be responsible for enforcing access restrictions and talking to a database.

This is what I'm struggling with when it comes to weighing the pros and cons of GraphQL. I like the SQL model, ie pushing selects and joins and such to the DB, so why not from client to host too? But when you still need to enforce access restriction and such per user per action, how much time would it save me, really?

Seems great for internal apis or prototyping though.

[tensor]

Hasura and Postgraphile both use row level security for access restriction. Anyone can still execute a query, but they won't get back data they don't have access to.

[nirvdrum]

While doable, you probably don't really want a web client talking directly to your RDBMS, if for no other reason than connection management would be a nightmare. The calculus there might be different if using something like DynamoDB, but I suspect you'd still find it challenging to be littering your code with DynamoDB calls. So, at some point you'd build your own little utility classes to abstract away the DB interaction, much like an ORM, and eventually it'll evolve into something with overlapping functionality of GraphQL.

If you accept that you don't want your web client talking directly to the database, then you need something that will interface with the database. That problem has been around for a while with many different solutions: SOAP, ReST, PouchDB/CouchDB, interface with various cloud services, something completely custom, and many others. GraphQL is just one of the latest solutions to that problem and with it, brings some advantages around flexibility in the API requests and responses. It also makes it easy to stitch together multiple GraphQL APIs. So, by being standardized* you don't need to develop the client code yourself and you gain the ability to pull together APIs from multiple sources to present as a single end-point. The most popular clients also provide caching mechanisms so you don't have to keep whacking the back-end for the same data repeatedly. There's also graphiql [1], which gives you a really nice way to query or modify your data on any GraphQL API, which I've found to be very helpful when learning new APIs.

So far, I've found GraphQL most useful for single page applications where the back-end really doesn't have to do much more than handle DB interactions. If you already have an application up and running with little churn in the API, adopting GraphQL probably wouldn't gain you much. In a greenfield application, I was able to use Hasura to replace a simple Rails CRUD application and that was handy. Hasura also takes care of JWT handling, so I could do my auth with Auth0 and not handle that in Rails either. I think GraphQL solves an interesting part of the serverless puzzle.

Don't get me wrong, GraphQL can be downright frustrating at times. Or at least the popular implementations of it can be. We use Relay at work and while it solves a lot of problems, it introduces many of its own that have cost me hours of frustration. I tried using AWS Amplify on a side project, and having to write new AppSync resolvers with Velocity templates is just not pretty. It really took using Hasura for me to finally be sold on what the GraphQL promise could be (side note: Hasura doesn't support the Relay protocol, so if that's important to you, you'll need to find a different tool).

* -- Standardized is a loose term. There is a GraphQL spec, but it leaves a lot available to implementation details. So, then there are other specs, such as Relay, built on top of that. Or de facto standards based on what the popular clients provide.

[1] -- https://github.com/graphql/graphiql