That's something you should only really do in development, and then cement for production. Having open queries where an attacker can find interesting resolver interactions in production is asking for trouble

▲

Aurornis 2 days ago | parent | next [-]

> That's something you should only really do in development, and then cement for production

My experience with GraphQL in a nutshell: A lot of effort and complexity to support open ended queries which we then immediately disallow and replace with a fixed set of queries that could have been written as their own endpoints.

	▲	twodave 2 days ago \| parent [-]
		This is not the intended workflow. It is meant to be dynamic in nature.

▲

fgkramer 2 days ago | parent | prev | next [-]

But has this been thoroughly documented and are there solid libraries to achieve this?

My understanding is that this is not part of the spec and that the only way to achieve this is to sign/hash documents on clients and server to check for correctness

▲

verdverm 2 days ago | parent | next [-]

Well, it seems that the Apollo way of doing it now, via their paid GraphOS, is backwards of what I learned 8 years ago (there is always more than one way to do things in CS).

At build time, the server generates a random string resolver names that map onto queries, 1-1, fixed, because we know exactly what we need when we are shipping to production.

Clients can only call those random strings with some parameters, the graph is now locked down and the production server only responds to the random string resolver names

Flexibility in dev, restricted in prod

▲

girvo 2 days ago | parent | prev [-]

I mean yeah, in that Persisted Queries are absolutely documented and expected in production on the Relay side, and you’re a hop skip and jump away from disallowing arbitrary queries at that point if you want to

Though you still don’t need to and shouldn’t. Better to use the well defined tools to gate max depth/complexity.

▲

verdverm 18 hours ago | parent [-]

All these extra requirements are why GraphQL never really captured enough mindshare to be a commonly selected tool

	▲	girvo 14 hours ago \| parent [-]
		> GraphQL never really captured enough mindshare to be a commonly selected tool It has been, at the scale it matters and should be used at. Most companies don't operate at that scale though.

▲

hdjrudni 2 days ago | parent | prev [-]

Sure, maybe you compile away the query for production but the server still needs to handle all the permutations.

	▲	verdverm 2 days ago \| parent [-]
		yup, and while they are fixed, it amounts to a more complicated code flow to reason about compared to you're typical REST handler Seriously though, you can pretty much map GraphQL queries and resolvers onto JSONSchema and functions however you like. Resolvers are conceptually close to calling a function in a REST handler with more overhead I suspect the companies that see ROI from GraphQL would have found it with many other options, and it was more likely about rolling out a standard way of doing things