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.

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’re excited to announce that our metrics product now allows you to filter your metrics by a specific date/time range. Our new date range picker UI gives you precision down to the minute and makes it much easier to analyze your data.

You can find the newly added calendar picker next to the relative time picker. This intuitive tool lets you easily select dates by clicking on the calendar days.

For those who require a more precise selection, you can go down to the minute level with the input fields below the calendar.

This feature is now live and available for immediate use. We hope that this enhancement will significantly improve your experience. We welcome your feedback and look forward to hearing about your experiences with this new functionality.

We just launched a set of features that will help you understand the reason behind a cache hit, miss or pass. Now, when looking at a request, you’ll be able to see the applied caching rules, this can help you debug why an operation was or was not cached as you expected.

If you check the operation details, you’ll see a similar view, this one is particularly useful if you want to change your stellate configuration and understand the impact it will have in your operations. For example, you could change your config, and take a look at your top operations to see how your rules are affecting it.

And in the scenario where a request is a pass, we'll show you a more explicit reason

This is now live at stellate.co, we can't wait for you to try it!

Introducing our theoretical cache hit rate: a powerful tool to help understand the maximum achievable cache hit rate for a particular operation, factoring in all possible variable and scope combinations.

Consider an operation that has been requested 1,000 times within the past 24 hours. If there is only a single unique combination of variables and scopes for this operation, and we set a max-age of 24 hours, we would encounter a single cache miss. This leads to a remarkable 999 cache hits. Therefore, the theoretical maximum cache hit rate would be 99.9%, calculated as 999/1000.

A good example of such an operation might be a posts query for a blog, which typically has consistent variables and scopes.

Contrast this with an operation with higher variable diversity, such as a search query. For 1,000 requests, we might observe 800 unique variable combinations. In this scenario, Stellate will cache 800 requests upon their first encounter. This could result in up to 200 cache hits, yielding a theoretical maximum cache hit rate of 20%.

We are delighted to announce that this insightful feature is now readily available in the operations view for all services! Please explore its potential to optimize your caching strategies.