Making changes to the cache configuration can be scary. Even more so if I have a big GraphQL schema with lots of types and fields to keep in mind. What if I accidentally cache something that should not be cached? Or worse, what if that leads to my cache leaking sensitive data to other users!?

We believe it's important for you to feel confident when making changes to your cache configuration. A big part of this is acknowledging that certain types and fields just must not be cached, ever.

Today we're making it even easier for you to configure non-cacheable types and fields in your Stellate configuration. We're launching a new configuration property called "nonCacheable" where you can specify a list of type and field names that Stellate must never cache.

If Stellate finds one of these types or fields inside the query response, it will not store the query in the cache.

If you're already a Stellate fan, the concept of block-listing types and fields might seem familiar to you. And that's because it is! We had support for this behavior for a long time, in particular by adding a "special" cache rule for those types and fields with a max-age of zero. However, we found this to be a confusing way of exempting types and fields from caching as it looks just like any other cache rule which generally should include types and fields in the cache.

Of course, we're keeping everything backward compatible, so if you're using the "old" approach your cache configuration still works as expected.

We hope that this will help increase your confidence in making changes to your cache configuration. You can read all about the new config property in our documentation.