Skip to content

Using keyArgs for nested argument names. Cache strategy for time-range pagination. #651

Description

@valentynapolienova

Hi!

Problem

I’m fetching historical data e.g.

                  type Query {
                    priceHistory(input: PriceHistoryInput!): PriceHistoryResult
                  }

                   input PriceHistoryInput {
                     quoteId: Long!
                     userId: Long!
                     currencyId: Long!
                     unitId: Long!
                     page: Int
                     pageSize: Int
                     to: ISODateTime
                     from: ISODateTime
                  }

where
from and to are time-range filters that I floor/ceil for efficiency
• I’d like the cache to treat all requests with the same quoteId as the same underlying list, regardless of the exact from/to bounds
• So I’d like to exclude from/to from the cache key (i.e., not include them in keyArgs) and then rely purely on a merge function to combine the list of results, when the next day starts, for example
• But because my arguments are nested under input, I’m uncertain how to configure keyArgs in Ferry to say something like “only include input.quoteId, exclude input.from and input.to”, or otherwise achieve this behaviour.
• I have tried specifying keyArgs: ['input.quoteId'], but I observe that it is not supported.
• I can use a merge on the field policy, which helps combine lists in the same cache key, but since each time range is stored under a different key, the merge never runs across time-ranges.
• Another problem is that I’m implementing time-range pagination (not page-based pagination). To load more results, I change the from and to values.

Questions

Could you please clarify:
1. Does Ferry currently support excluding specific nested arguments (e.g., input.from, input.to) from the cache key while including others (e.g., input.quoteId)?
2. If yes: what is the exact syntax / pattern for keyArgs to handle nested input types in this way?
3. If no: could this capability be considered as an enhancement? Or is the intended pattern to always include all arguments and rely entirely on merge?
4. Are there any documented examples for range / history pagination queries using nested input types with on-cache merging? Cause I'm not sure this is the right direction I'm looking.

Thanks in advance for the help and feedback!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions