Hi all Does anyone have any pointers on caching I m trying t kotlinlang #apollo-kotlin

Hi all! Does anyone have any pointers on caching? ...

Seb Jachec

10/21/2021, 12:54 PM

Hi all! Does anyone have any pointers on caching? I'm trying to cache & re-use the output of a query for multiple items for another query for a single item (going from a list of items to a detail screen for one). Using 3.0.0-alpha07 with a normalized cache. Simplified sample below I've changed the cache key format for an 'entry' to

Entry.<id>

using `ObjectIdGenerator`/`CacheKeyResolver` but I'm getting a cache miss for

EntryQuery

–

Object 'QUERY_ROOT' has no field named 'entry({"input":{...}})'

, before the inner

Entry

from

EntryOutput

can even be looked up in the cache (which I'd expect to succeed)

Copy code

type Entry {
	id: ID!
	# ... etc
}

query EntriesQuery(...) {
	entries(input: { ... }) { # produces EntriesOutput
		nodes { # [Entry]
			id
		}
	}
}

query EntryQuery($entryId: ID!) {
	entry(input: { entryId: $entryId }) { # produces EntryOutput
		entry { # Entry
			id
		}
	} 
}

mbonnin

10/21/2021, 1:16 PM

I'd recommend using
@fieldPolicy
for this instead of writing
ObjectIdGenerator
/
CacheKeyResolver
manuallly. There are sadly no docs yet (it's coming) but there are some integration tests there: https://github.com/apollographql/apollo-android/blob/2ca7d9b7805197ce388c9e96e65ce[…]/commonTest/kotlin/test/declarativecache/graphql/extra.graphqls

mbonnin

10/21/2021, 1:17 PM

Mmmm but

input

is an input object. Not sure if that works already

mbonnin

10/21/2021, 1:18 PM

How do you get the

Entry

id from

input

Seb Jachec

10/21/2021, 1:37 PM

Sorry, might have left too much out of my sample! The

input

for the

entry

query has

entryId

mbonnin

10/21/2021, 1:52 PM

Thanks! So you'll need to use that in your

CacheKeyResolver

mbonnin

10/21/2021, 1:56 PM

Something like this should do it:

Copy code

object CustomCacheKeyResolver: CacheKeyResolver() {
  override fun cacheKeyForField(field: CompiledField, variables: Executable.Variables): CacheKey? {
    if (field.name == "entry") {
      val input = field.resolveArgument("input", variables) as? Map<String, Any?>
      val id = input?.get("entryId") as? String
      if (id != null) {
        return CacheKey(id)
      }
    }
    
    // Fallback
    return null
  }
}

Seb Jachec

10/21/2021, 2:18 PM

Ah, that's actually pretty much identical to the custom

CacheKeyResolver

I'm using at the moment, alongside my `ObjectIdGenerator`:

Copy code

val objectIdGenerator = object : ObjectIdGenerator {
    // Called after a network request, when writing to the cache
    override fun cacheKeyForObject(
        obj: Map<String, Any?>,
        context: ObjectIdGeneratorContext,
    ): CacheKey? {
        val typeName = obj["__typename"].toString()

        if (obj["__typename"] == "Entry") {
            val id = obj["id"].toString()
            return CacheKey.from(typeName, listOf(id))
        }

        return null
    }
}

mbonnin

10/21/2021, 2:20 PM

Do you mind sharing your

CacheKeyResolver

Seb Jachec

10/21/2021, 2:21 PM

Sure:

Copy code

val cacheResolver = object : CacheKeyResolver() {
    override fun cacheKeyForField(
        field: CompiledField,
        variables: Executable.Variables,
    ): CacheKey? {
        return if (field.name == "entry" && field.type.leafType().name == "Entry") {
            val input = field.resolveArgument("input", variables) as? HashMap<*, *>
            return input?.let {
                val entryId = input["entryId"].toString()
                CacheKey.from("Entry", listOf(entryId))
            }
        } else {
            null
        }
    }
}

👍 1

mbonnin

10/21/2021, 2:24 PM

Thanks!

mbonnin

10/21/2021, 2:24 PM

Can you check if the non-null return case gets hit?

mbonnin

10/21/2021, 2:27 PM

Might also be worth using

store.readOperation()

directly to rule out an issue in the cache interceptor or something else

Seb Jachec

10/21/2021, 2:32 PM

The non-null return case doesn't get hit with my current

CacheKeyResolver

–

cacheKeyForField

gets called for

EntryOutput

first, then I get a cache miss, without the chance for

cacheKeyForField

to be called for the inner

Entry

inside

EntryOutput

Seb Jachec

10/21/2021, 2:32 PM

Thanks for the tip on

readOperation

– I'll check that next!

mbonnin

10/21/2021, 2:33 PM

Aaaaahh I think I just got it!

mbonnin

10/21/2021, 2:33 PM

Sorry I missed the

EntryOutput

wrapper type

mbonnin

10/21/2021, 2:34 PM

Damn, that's not an easy one. Your

EntryOutput

type doesn't have an

id

itself

mbonnin

10/21/2021, 2:35 PM

Copy code

query EntryQuery($entryId: ID!) {
	entry(input: { entryId: $entryId }) { # Entry or EntryOutput ?

is entry of Entry or EntryOutput type up there ?

Seb Jachec

10/21/2021, 2:36 PM

Ahh, I hadn't thought about that actually. Another error on my part!

EntryOutput

does actually have an

id

, but I hadn't been querying for it/using it at all –

Copy code

type EntryOutput {
  id: ID
  node: Entry
}

mbonnin

10/21/2021, 2:38 PM

Copy code

query EntriesQuery(...) {
	entries(input: { ... }) { # produces EntriesOutput
		nodes { # [Entry]
			id
		}
	}
}

This is weird then... Is that a double list?

mbonnin

10/21/2021, 2:38 PM

Ah no got it,

EntriesOutput

EntryOutput

👍 1

mbonnin

10/21/2021, 2:38 PM

Damn

mbonnin

10/21/2021, 2:40 PM

TBH, I think the easiest path there would be to update your schema to use something relay-like

mbonnin

10/21/2021, 2:41 PM

As it is now, it's super hard to reconcile

QUERY_ROOT.entries

and

QUERY_ROOT.entry

since they have different types

Seb Jachec

10/21/2021, 2:57 PM

Hmm okay, thanks Martin; would you be able to elaborate on a 'relay-like' schema? If it adds any context to this scenario, the

input

for our

EntriesQuery

is has

start

and

end

DateTime

objects at the moment, so we're querying for a range of entries

mbonnin

10/21/2021, 2:59 PM

In a lot of schema, you'll find relay connections: https://relay.dev/graphql/connections.htm

mbonnin

10/21/2021, 3:00 PM

Actually, in your specific case, maybe you "just" need to remove

EntryOutput

and return an

Entry

instead. I think that'd do the job

Seb Jachec

10/21/2021, 3:07 PM

That's a good point, thanks for the tip on relay too. I'll look into this some more

👍 1

Seb Jachec

10/26/2021, 2:16 PM

Came back to this to test some schema changes 😅 Both

EntriesQuery

and

EntryQuery

now return the same type (

EntryConnection

), with cache keys for

EntryNode

and

EntryEdge

in the format

EntryNode:<id>

and

EntryEdge:<id>

respectively. It still doesn't seem possible to reconcile these though – would you have any suggestions on what to try next?

Copy code

type EntryConnection {
  edges: [EntryEdge!]!
}

type EntryEdge {
  id: ID!
  node: EntryNode!
}

type EntryNode {
  id: ID!
  # Other fields left out (title etc.)
}

mbonnin

10/26/2021, 4:59 PM

EntryQuery

should return an

EntryNode

. There's no real need for a Connection if it's a single entry

Seb Jachec

10/27/2021, 10:20 AM

That makes a lot of sense actually – made that change, and managed to get our list & detail queries reconciled nicely, thanks a lot for your advice Martin!

mbonnin

10/27/2021, 12:39 PM

Nice! Glad to hear it worked out well blob smile happy

97 Views

Open in Slack

Previous Next