[ttfkam]

Not particularly scary. For something like Hasura, resolvers are opt-in, not opt-out. So that should alleviate some of your concerns off the bat.

For Postgraphile, it leans more heavily on the database, which I prefer. Set up some row-level access policies along with table-level grant/revoke, and security tends to bubble up. There's no getting past a UI or middleware bug to get the data when the database itself is denying access to records. Pretty simple to unit test, and much more resistant to data leakage when the one-off automation script doesn't know the rules.

I also love that the table and column comments bubble up automatically as GraphiQL resolver documentation.

Agreed about the introspection tools. I can send a GraphiQL URL to most junior devs with little to no SQL experience, and they'll get data to their UI with less drama than with Swagger interfaces IMO. (Though Swagger tends to be pretty easy too compared to the bad old days.)

[RHSeeger]

But as people noted, it's not the "can this get the data" unit testing that's a problem here. It's the performance issues.

> I can send a GraphiQL URL to most junior devs with little to no SQL experience, and they'll get data to their UI with less drama

But that's like giving direct (read) database access to someone that was taught the syntax of SQL but not the performance implications of the different types of queries. Sure, they can get the data they want; but the production server may fall over when someone hits the front end in a new way. Which is, I think, what a lot of people are talking about when they talk about GraphQL having load issues based on the front end changing their call.

[ttfkam]

Hasura and Postgraphile are quite performant. No complaints there.

And you can both put queries on an allow list, control max query depth, and/or throttle on query cost.

[danielheath]

> put queries on an allow list, control max query depth, and/or throttle on query cost.

All of which are features which give you some way to respond to the performance issues you avoid by planning your API up-front.

[ttfkam]

None of those are automatic. Any API you write still has to remember to put in LIMIT clauses, to avoid OFFSET. And then you have to actually write the API rather than have it generated for you.

There are no free lunches, especially with regard to security and sanity checks.