We've made a host of improvements to Partial Query Caching (PQC), elevating it to public beta. PQC is now suitable for gradual adoption in production workloads. Recent enhancements include list handling, dashboard insights, algorithm optimization, and more. You can read more in our docs. If you'd like to use PQC or learn more about it, please reach out to support@stellate.co

The stellate_cache directive enables you to define cache rules directly in your GraphQL schema. You can configure the maxAge, SWR and scope for both types and fields. The changes in your schema will automatically be applied to your Stellate service by your CI on your next deploy using the existing stellate push CLI command. Learn more in our docs.

Dynamic Scopes, now in Beta, lets you evaluate the contents of headers and cookies using a JS function, enabling you to define scopes dynamically. Learn more over in the docs.

import { Config } from 'stellate'
const config: Config = {
  config: {
    scopes: {
      // ctx is an object with the following properties:
      // - headers: an object with all headers of the request
      // - cookies: an object with all cookies of the request
      AUTHENTICATED: (ctx) => {
        const userId = ctx.cookies.uid
        if (!userId || userId.startsWith('lo_')) {
          return 'UNAUTHENTICATED'
        }
        return userId
      },
    },
  },
}

export default config

We have recently announced the new feature of previewing the impact of changes to the caching rules in your configuration.

In the next iteration we worked on the visual clarity.
The preview now opens in a modal instead of a new window. From there, the changes can be applied and saved directly.
Instead of breaking down to rules, we now break down into these three categories: Newly Cacheable, No Longer Cacheable, and Updated Cache Configuration. These categories list all affected operations and their associated cache rules.

We added a new config field that allows you to customize the title of your GraphiQL instance. This is useful when you want to open up your API and want a descriptive page title.

To customize the title you can add a graphiql config key with title and enabled properties to your Stellate Config:

Learn more about Stellate's config in our docs.

We’ve heard from many customers that they are not confident about the impact of changes to their config rules. As a result, they double-check their work and run experiments to verify that the changed config caches the things they intended and more importantly, doesn’t cache things they didn’t intend.

To make the impact of cache config changes more visible we’ve built a new page where you can see the impact of new or updated caching rules on your existing operations right in the UI before saving your config changes.

For power users who prefer managing their config through git and the CLI we’ve also added CLI support:

stellate config preview [--service <service name>] [--browser]

This command generates a link to your Stellate dashboard where you can see the impact of your changes on your recent operations. The --browser flag will open the link in your default browser.

We hope this helps our customers feel confident when making changes to their caching config. We are already working hard on the next iteration of “the preview tool” and welcome your feedback.

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.

When looking at the cache hit rate over time chart, now you will see an indicator for when a new config version is published. This will help to understand if there was a cache hit increase/drop when your caching rules change.

This is now live for all Stellate services.

Today, we are releasing a significant update to our Cache Hit Rate (CHR ) calculation. This revised formula will take into account all cacheable traffic, including HITs, MISSes, and now PASSes that could potentially be cached.

What does this mean for your Stellate services

You might notice a noticeable decrease in the CHR value for your service. However, it's essential to understand that this doesn't imply a sudden decrease in your cache performance. Instead, it results from the new, more comprehensive calculation formula.

Why did we made this change

This decision has been driven by deep thought and consideration, in alignment with our mission to provide the most relevant and meaningful data for your caching needs. We aim to make the CHR metric more accurately represent the cacheable traffic, allowing for deeper insights, such as revealing the Max CHR for specific operations

We hope this provides transparency into the change, you learn more about caching in our docs. If you have any questions or concerns, please reach out to our support team at support@stellate.co.