Feature Request: Support for pre-processing and/or validation before resolvers begin running

[spruke]

I've been building an enterprise-tier product in AppSync and so far it's really living up to the task, but as the list of needs for the enterprise system grows, there are a couple things I find myself unable to do, and many of them would all be solvable with the same solution: support for a preprocessing lambda and postprocessing lambda at the entire-API level, such that can execute before your resolvers begin running or after total resolver execution has concluded, especially for checks that need vision on the whole GraphQL query in order to make sense.

Use cases:

Protect against nested attack that wastes resources

query {
  getAuthor(authorId: "12345") {
    name
    books {
      title
      authors {
        name
        books {
          ... ad naueseaum
        }
      }
    }
  }
}

This is valid graphql a Client can ask your API for that the only defense against is not to make resolvers that go both ways on your types. Obviously there is a business case for seeing Books of an author as well as Authors of a Book. Individual resolvers don't have visibility on the entire query that was asked for and can't defend against this. A preprocessing lambda that had visibility of the entire query could stop it.

Defense against getting unauthenticated records by going up the chain then down the chain

query {
  getTwitterUser(userId: "12345") {
    userHandle
    tweets {
      content
      retweetedByUsers {
        userHandle
        tweets {
          ... could be backing into things i'm not allowed to see here!
        }
      }
    }
  }
}

This is an oversimplified example above, but essentially, you can break the @auth pattern that has been so useful in establishing ownership of certain rows, by asking for something that passes the auth check, then nesting into children, then nesting back out to their parents, then continuing to chain those nestings until you can see things you don't have access to. There are workarounds for this, but they all involve going in and getting really dirty in your resolvers with having to traverse all the way back up the chain and checking @auth again manually. Again, could defend against this from the very top level by having a preprocessing lambda that has visibility to see the entire graphql query.

Taking a certain action on all resolvers without having to attach a pipeline function to all of them

We're up over 300 resolvers now in our API and there are some pretty universal transforms we do on all of them, such as doing an extra layer of authentication check against a source that isn't one of the AppSync premade auth sources, and writing an event to an Event Bus Architecture if the graphql call was a Mutation. Our solution to this has been to make some extra FunctionConfigurations and attach them to the PipelineConfigurations on each of the... 300+... resolvers. That's a code smell for sure. This would definitely be a real win if there was a global API-tier preprocessing and postprocessing lambda.

Conclusion

Thank you for considering my feature request!

[itrestian]

Thanks! Adding pre or post execution hooks is on our roadmap. I will add a +1 to your feature request.

[spc16670]

+1