hasura-con-22

Catch the HasuraCon’22 Recordings

Add Caching to existing GraphQL APIs

Get faster response times with Hasura Cloud Caching

Caching is now available on the free tier
  • TickAutomatic caching of authenticated data
  • TickQuery caching at the database level
  • TickBlazing fast performance

The problem with web caching

Caching is hard

GraphQL is transport agnostic. Most server implementations in GraphQL, including Hasura use the HTTP REST API style for making requests.

What does it impact? GraphQL cannot leverage existing patterns for REST APIs. All requests are HTTP POST requests and they cannot be cached. GET requests have limitations around query string size.

What’s slowing down your queries?

Typically, there could be latency and slow response times for GraphQL queries due to

  • AlertSize of the response
  • AlertLocation of the server
  • AlertNo. of concurrent API calls

How does caching work with Hasura?

A GraphQL query’s response can be cached by Hasura for various use cases
  • TickThe query can be from any external GraphQL server added via Remote Schemas
  • TickAuthenticated queries can be cached by Hasura as long as session variables are not used
  • TickHasura caches response JSON upto 100KB in size.
Cached responses are stored for a period of time in a LRU (least-recently used) cache, and removed from the cache as needed based on usage.
Hasura has metadata about the data models across data sources, and the authorization rules at the application level. This helps Hasura provide end-to-end application caching.
How does caching work with Hasura?

Parameters involved in GraphQL caching

Server side caching
Server side caching
Typically gateway caches are used to check if the data is still up to date in the cache to avoid additional round trips.

The advantage is that Hasura doubles up as your server side cache.
Client side caching
Client side caching
Client side caches at the browser level use HTTP caching to avoid refetching data that is still fresh. This is set by response headers by the server for the request. GraphQL Clients cache data with an in-memory cache.
Cache freshness
Cache freshness
Control the number of times a resource should be considered fresh with response headers like Cache-Control. This is typically well suited for data that doesn’t change in real time or as often as up to 5 mins.
Cache expiry
Cache expiry
Control cache lifetime with Hasura using the “ttl” argument on the `@cached` directive.

Features

Cache authenticated data

Cache authenticated data

  • Hasura has information about the data models of your application and the authorization rules to offer an end to end caching solution
  • Cache shared data with invalidation logic
  • Automatic cache invalidation with ttl config for refreshing stale data
Cache authenticated data
Caching at the database layer

Caching at the database layer

Hasura uses PostgreSQL prepared statements where parsing is skipped and only planning and execution takes place.

  • GraphQL query plans get cached at Hasura: This means that the code for SQL generation, adding authorization rules etc doesn't need to run repeatedly.
  • SQL query plans get cached by Postgres with prepared statements: Given a SQL query, Postgres needs to parse, validate and plan it's own execution for actually fetching data. A prepared statement executes significantly faster, because the entire execution plan is already "prepared" and cached!
Caching at the database layer
Cache any Remote GraphQL API

Cache any Remote GraphQL API

Hasura Cloud supports query response caching for Remote Schemas. This lets you cache any other custom GraphQL API that you have written or any external GraphQL API from services such as GitHub, Contentful, GraphCMS and so on.
Cache any Remote GraphQL API
Generate REST APIs for traditional caching

Generate REST APIs for traditional caching

Hasura lets you generate REST APIs from GraphQL. Now these REST APIs can be cached using typical HTTP caching tools and techniques.

  • Cache GET endpoints using CDNs
  • Use HTTP status code for valid responses
Generate REST APIs for traditional caching
Client Side Caching

Client Side Caching

  • Hasura GraphQL Endpoint works with popular GraphQL Clients like Apollo Client and urql and their normalized cache
  • Optimistic UI updates after making a mutation request. Read more Optimistic UI and Clobbering

Ready to get started with caching?

Frequently Asked Questions

What is GraphQL Caching?
Caching in GraphQL can be implemented on both the server side and client side. On the server side, caching a GraphQL query would typically involve storing the results in a low-latency document storage database like Redis. Hasura lets you cache GraphQL queries to improve application performance.
How is caching in GraphQL different from REST API?
Caching in traditional REST APIs use the HTTP methods and endpoints to cache the APIs server side. Since GraphQL is typically a HTTP POST request, it needs to be handled differently.
What kind of caching does Hasura support?
Hasura Cloud supports GraphQL query response caching. Read more about Query Response Caching
How to clear a cache for the GraphQL request?
You can make use of the “refresh” argument in the @cached directive to indicate that the old cache needs to be cleared and refreshed.
How long can data be stored in a cache?
Hasura supports cache lifetime of upto 300 seconds. You can specify this time using the “ttl” argument of the @cached directive.
Monthly product updates in your inbox. No spam.
Loading...
News letter