Allow configure expiration time

[DmitryTsepelev]

trafficstars

[qen]

@DmitryTsepelev instead of expiration time, we need to be able to association the hash to a last_modified_at value for http get cache

in a standard restful api we would have something like this in the controller

respond_to do |format|

  format.json do

    last_modified = get_the_max_updated_at # will only query just 1 record from the db

    if stale? last_modified: last_modified
      # full db query here
    end
  end
end

so i am thinking we need to have something similar for graphql, it could probably look like this

last_modified = V1::Schema.last_modified_call_back( query ... )
if stale? last_modified: last_modified
  result = V1::Schema.execute(query, variables: variables, context: context, operation_name: operation_name)
  render json: result
end

i think the challenge here is that how to associate the query to a last_modified date value

[DmitryTsepelev]

Hi @qen! You can do exactly the same thing in GraphqlController, but you have to somehow understand, what query is coming, and, due to graph nature—it's hard (but you can agree that same queries have same operation name, for instance). The second problem is that, when you cache parent query, it cannot understand, that child (nested) fields were changed.

That's why I use a different approach—framgent caching, check it out and let me know if it helps 🙂

[qen]

hello @DmitryTsepelev

thanks for that ill look into it, i am still new to the graphql

i was actually looking into associating the cache key of the query, and the GID value of the model together with the updated_at

and what i am thinking is somewhat similar approach discussed here https://graphql-ruby.org/schema/object_identification.html

but instead it returns the timestamp and model gid value

once i received the compiled query cache key and got the gid and timestamp, i just need to fetch the updated_at value of the model using the gid

all of this however is with the assumption of using redis as the cache backend

[DmitryTsepelev]

My point was that if, for instance you fetch user with orders (query { user { email orders { id } } }) and use user's updated_at to cache the response, client won't see any new orders until user is updated (which would make you to touch all associations each time you update something)

[qen]

yeah i understand that, at least for our use case, i find that acceptable

my assumption is that, the client side will only make a get request only if it has the query cache key

the way i see it is that, every time a post request is made, it will then keep the timestamp and gid associated with the cache key updated, so when the client side makes a get request the associated timestamp and gid is recent data