Feature Request: Per request session store for DataLoader

[vicary]

This feature is quite similar to the current $context.stash in Pipeline Resolvers, expanding the storage scope and lifetime into the whole GraphQL request.

This let users easily implements their own logics similar to graphql/dataloader, resolving the N+1 problem altogether.

Existing alternatives are,

1. BatchInvoke. It somehow reduces the latency into N/5+1, but still when working with paginated data the latency is not pretty.
2. ElastiCache. This requires VPC in Lambda resolvers, which increases cold-start time a little bit also have some network overhead.

If income generation is one of the concerns, we are willing to follow the same pricing model as ElastiCache, but without the network overhead of connecting it via Lambda. I'd like to enjoy the single-digit milliseconds latency (sampled from X-Ray) where AppSync achieves at resolver mapping template level.

[ndejaco2]

Hi Vicary thanks for your request :) Are you using VTL with your lambda resolvers or just direct lambda? What kind of cache keys would you like to use with the per request cache? Would an AppSync internal dataloader cache that ensures duplicate resolver inputs on the same field/type can be served without making extra lambda invocations satisfy your use case?

[vicary]

@ndejaco2 Thanks for the reply, answering your questions below.

Are you using VTL with your lambda resolvers or just direct lambda?

We are mostly using Direct Lambdas, but if VTLs are necessary to interface with the cache, we are totally happy to work with it.

What kind of cache keys would you like to use with the per request cache?

Mostly the __typename and ID, which sometimes may not be immediately available from resolver inputs, it maybe resolved from the authentication token and multiple levels of $context.source. So, following the reasoning above, we are totally happy to split this into a pipeline resolver and resolve the cache key in a separate pipeline function before interfacing with the cache.

Would an AppSync internal dataloader cache that ensures duplicate resolver inputs on the same field/type can be served without making extra lambda invocations satisfy your use case?

Yes, that should solve 80% of our use cases and supersedes the requirements above. This maybe not the most flexible way, but definitely something to work with for all these years. I am very much appreciated If this feature is within your radar, we can refactor our resolvers around it.

[p-mercury]

I am currently searching for a way to elegantly add graphql/dataloader type behaviour to my AppSync resolvers as I have detailed in this question and this enhancement request seems to do exactly that, so I wanted to ask if there are any updates on this topic?

Because the only way I can see to currently solve the problem of duplicate requests and N+1 is using some very cumbersome resolver logic that would almost be unmaintainable