aws / aws/aws-appsync-community

AppSync caching of a nested resolver on an array field

Open
#254 0 comments 0 reactions 0 assignees View on GitHub
pending triage
Dominant language
HTML
Stars
507
Forks
37
PR merge metrics
No merged PRs in 30d

Description

### Context

I am trying to set up AppSync caching for a nested resolver. The field itself is an array of objects.

```
- type: CoolFoos
kind: PIPELINE
field: foos
request: foos/Transform.flattenIds.request.vtl
functions:
- GetFoosNRFunction
caching:
keys:
- $context.source.foos
ttl: 300
```

In short
- `foos` is `[IdObject]`
- `$context.source.foos` is an array of `{id: string}` objects
- nested resolver replaces it with an array of concrete domain objects retrieved from a service
- `foos` becomes `[Foo]`

### Problem

I could not find a way to set a unique caching key based on the values of `$context.source.foos`. What I've tried was:
- `$context.source.foos` (array of objects)
- `$context.source.foos.id` (name of the enclosed object field)
- `$context.source.ids` (result of the BEFORE request mapping - all ids as single string)
- `$context.source` (complete source)

None of these worked. Responses are not being cached (no cache hits, each subsequent request hits the `GetFoosNRFunction`).
When I replaced `keys` with `$context.identity.sub` it worked, so it's obvious that the keys built from `$context.source` did not work.

Is this a supported use case? What am I missing?

Contributor guide

Open the contributing guide

Research direction

Start with the AWS AppSync caching configuration for the nested PIPELINE resolver and the mapping-template inputs named in the issue: $context.source.foos, $context.source.ids, and $context.identity.sub. Reproduce the GetFoosNRFunction requests with array-of-object cache keys and compare cache hits. Done means establishing whether this key shape is supported and identifying the required key form or limitation.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, graphql
Domain
api, backend-api-design, performance
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.