If you are using WordPress, WPGraphQL, and Stellate, you should also look into our Stellate WordPress plugin, which will take care of invalidating any data you changed in your Stellate Edge Cache.
This plugin is available via the WordPress Plugin Directory. See the plugins page at https://wordpress.org/plugins/stellate/.
Before you start, make sure you have signed up for a Stellate account, and have created a service already.
You can keep the default 15-minute cache rule in place, however, we would recommend tweaking (and adding additional) cache rules to optimize the value you get out of the Stellate Edge Cache. Keep in mind that the plugin takes care of invalidating cached responses if you make changes to your WordPress content, so you might want to increase the
swr values considerably.
The Stellate WordPress plugin requires WPGraphQL version
1.7 or newer. It
will not work with earlier versions of the plugin.
In your WordPress installation, navigate to Plugins --> Add New, search for Stellate and click the Install Now button. If you need help with the installation, see WordPress documentation on plugins or feel free to reach out to us via the in-app chat.
Once you have activated the Stellate plugin, you will see a new Caching submenu in your GraphQL menu. You can configure all caching-related aspects from that menu item.
On the configuration screen, you will need to provide the name of your Stellate service. The service name is part of your dashboard URL:
You will also need to provide a Purging API token. You can generate those on your service's dashboard, by heading to Settings --> Purging API Tokens.
Purging API Tokens are separate from your regular Personal Access Tokens. They are configured via a specific services dashboard and only allow you to access the Purging API for that specific service.
You can further configure whether you want to use soft purging or not. Soft purging marks the cached response as stale, however, will still serve it until the data in the cache has been refreshed.
And you can purge your entire cache if you need to. Since this is a destructive operation, that might cause a significant load on your WPGraphQL service we do not recommend hitting that button lightly.
- The plugin handles automatic cache invalidation for all entities, including custom post types and taxonomies that are exposed via the GraphQL API.
- When creating entities (e.g. new posts, categories, ...) all cached responses for that type are purged. This is done to make sure any lists containing that type are invalidated and will show accurate data.
- The plugin will collect all entities that need to be invalidated and will send at most one HTTP request to the Edge Cache Purging API per request to the Wordpress backend.
- The plugin provides an action called
stellate_purge, which is called after each request to the Purging API. This action is passed an array with additional information on which entities were invalidated.
- If the specific invalidation request returns an error, the plugin will trigger a full purge (via a call to the
_purgeAllmutation) to make sure your users always get the most accurate information.
// Sample data passed to `graphcdn_purge` [ // `true` if everything has been purged 'has_purged_all' => false, 'purged_types' => [ // The names of the GraphQL types that have been invalidated completely ], // For each type we include an array that contains the exact ids of the // invalidated entities. The following show all "built-in" types. There // might be more if you use custom post types or custom taxonomies. 'Post' => [42, 43], 'Page' => , 'Category' => , 'Tag' => , 'Comment' => , 'Menu' => , 'MenuItem' => , 'User' =>  ]