verdverm 2 days ago

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

Reply View 9 replies
  • Aurornis 2 days ago

    > 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.

    Reply View 1 reply
    • twodave a day ago

      This is not the intended workflow. It is meant to be dynamic in nature.

      Reply View 0 replies
  • fgkramer 2 days ago

    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

    Reply View 4 replies
    • verdverm 2 days ago

      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

      Reply View 0 replies
    • girvo 2 days ago

      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.

      Reply View 2 replies
      • verdverm 16 hours ago

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

        Reply View 1 reply
        • girvo 12 hours ago

          > 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.

          Reply View 0 replies
  • hdjrudni 2 days ago

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

    Reply View 1 reply
    • verdverm 2 days ago

      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

      Reply View 0 replies