[andrewingram]

Query whitelist: Not trivial to do (properly) from scratch, but seems to be well-supported in library form.

Complexity caps: Depends on the server implementation. Sangria (Scala implementation) has it built in. For others, i'm not sure. It would be easier to add a depth cap, but a complexity cap is more useful. I think whitelisting and.or rate-limiting is the way to go if you're actually concerned about your GraphQL server being abused though.

[KirinDave]

Query whitelist: Takes the query language out of the game and makes the system indistinguishable from old pre-restful .cgi endpoints.

Complexity caps: In the absence of good query scheduling this is a defense mechanism by GQL server providers. Great. But why are we doing it in the first place. This is still more complex with nearly identical outcomes to restful endpoints.

[andrewingram]

A query white list is functionality identical to hand-written endpoints to serve each use case, except there's no hand-writing involved.

As long as you have a half-decent build pipeline and embrace static patterns on the client, you get to keep all of the benefits.

To be honest, you seem like someone who hasn't done a lot of client-side work, especially with component systems. The benefits to development speed and maintainability are significant, and nearly all the downsides can be mitigated.

If you're only approaching this from the perspective of a backend developer, i'd fully expect GraphQL to be underwhelming to you.

[KirinDave]

> A query white list is functionality identical to hand-written endpoints to serve each use case, except there's no hand-writing involved.

This isn't really graphQL though, is it? This is an ORM. The ones I work with (in Blu(cough)Python) the binding layer I use works off standard ORM stuff, and could route object retrieval out of a restful API with minimal developer work as well (AuthZ, AuthN).

> As long as you have a half-decent build pipeline and embrace static patterns on the client, you get to keep all of the benefits.

I guess I simply have no idea what the benefits are. I keep asking, people keep giving me "technical" benefits that I'm challenging and I've yet to really see any refutation to those challenges.

It keeps coming back to:

> The benefits to development speed and maintainability are significant

And okay, a query DSL is useful. I totally buy into this. In fact, I have made many query DSLs. I advocate for linguistic metaprogramming every chance I get.

But what I'm saying is that the way it's implemented (server side) is, in many ways, regressive. I think you'd get most of the same benefits from a service worker doing that arbitration and dispatch. Your query whitelist updates wouldn't require infrastructure pushes AND client pushes. You'd have better caching story (because SW would make it easier to cache both the intermediate queries and prevent refetch on the top level call).

My primary objection to GraphQL is just how immature the tooling is. And I know how to dive in and provide SDKs for solving some of these hard problems, but then we end up with the 2017 equivalent of a .cgi script and I'm just... I don't get why any architect would agree to that.

> i'd fully expect GraphQL to be underwhelming to you.

Then why push it down to me as a requirement? And why recommend outrageous "solutions" like "oh well we'll just query whitelist so you lose all your flexibility." "We implement internal complexity caps you have no way to perceive from the query language but don't worry we'll 400 your request so you know."

These seem, to me, to make your frontend experience objectively worse than restful calls.