See the latest new features, improvements, and product updates
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
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’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.
We are incredibly excited to announce that we have finished the biggest architectural improvement of the Stellate platform since our first launch in 2021!
You can read more about the project and what it means for you in our docs. But in short, these new improvements lay the foundation for:
Stay tuned for the announcements ahead as we leverage this new foundation to improve the platform for you.
It’s our responsibility to keep your services running smoothly, and we thank you for your trust. To honor that trust, we’ve done our best to make this transition as easy as possible and given you control over when to migrate your production traffic.
As of today, you can go to the settings for any of your existing services and toggle the new system on or off.
Services created from the 1st of August onwards automatically use the new system and can’t switch back to the legacy infrastructure.
Our support team is here for any questions you have before or after the migration. We’ve created a documentation page about the migration to make the transition as easy as possible.
This transition period begins today and allows your team 6 weeks to migrate proactively before the deadline on September 15th, when our team will be migrating all services. If you can not make the migration by that deadline and have concerns about your service being switched over, please reach out to our support team so we can work out a suitable migration path together.
We’ve made one potentially breaking change which all service owners should consider the implications of before migrating. If you limit the number of aliases allowed in queries or the overall byte size of the query, this is likely a breaking change for your use case. We advise that you raise the limits and test your application in staging before migrating your production service.
__typename insertions replaced with __stellate__internal__typename: __typenameWe’ve also introduced a few minor changes, which should have no functional impact on your services. You can read all about them in our extensive migration documentation.
data, errors, and extensions response fieldsWe hope that you will find this a smooth transition, and if you have any questions about or during this process, our support team is available for you.
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.
We just released a whole bunch of improvements for our requests page! We focused on bringing more clarity and transparency into how we present the data.
Going into the requests view now, the first thing you will notice is that we can now show different Cache Pass reasons and filter these out. This allows you to do things like filtering out non-GraphQL requests or focusing on queries that were a pass ("Prevented by Cache Rules") to discover new caching opportunities.
We also exposed more metadata fields from the request. Now you’ll be able to see:
We are explicitly calling out non-GraphQL requests, previously we showed these as "unkown query" which didn't indicate these were non-GraphQL. We are also showing explicit pass reasons for errors and mutations.
We hope all of these improvements make inspecting and debugging requests easier!
We're excited to announce a much-requested feature upgrade that we believe will significantly enhance your experience with our Stellate service. We're now providing the ability to cache introspection queries.
Here's how it works:
We have introduced a new configuration option: cacheIntrospection. This option allows you to set whether or not you want your introspection queries cached. You simply have to assign a boolean value to this option - true for enabling caching and false for disabling it.
Once enabled, your introspections will be cached for a duration of one hour, with a stale-while-revalidate policy of one day. This means your queries will be instantly available for an hour, and even after that, the old data will still be served while the cache revalidates in the background, making sure your applications are never interrupted.
A key benefit of this feature is that it automatically manages cache invalidation. Whenever a new schema is pushed, the cache will be invalidated automatically, ensuring the latest data is always available.
For new Stellate service users, the cacheIntrospection option will be enabled by default in your configuration. But if you're an existing user, no worries! You can easily turn on this feature by adding cacheIntrospection: true to your config.
🚫 ESC Autocomplete Popup Control
We've stopped closing the GraphiQL dialog with the ESC key, allowing you to close the autocomplete popup without unintentionally closing the entire dialog.
📏 Resizable GraphiQL Interface
We've added the ability to resize the GraphiQL interface, giving you more control over your workspace.
📺 Full-Screen Mode on Smaller Screens
For improved usability on smaller screens, we now automatically open GraphiQL in full-screen mode.
💾 Persisted Headers & Variables
We've made it so that headers and variables in GraphiQL persist, ensuring they're still available when you return or refresh the browser.
🎯 Auto-Focus Query Editor
The query editor now auto-focuses upon opening the modal, streamlining your editing experience.
We've upgraded our diffing algorithm to better understand the reordering of config items. As a result, it won't show a diff for reordered items, making the editing process much smoother.
To prevent crashes in certain cases, we now unquote JSON keys in the config. This simple change will significantly improve the editor's stability.
We've made the config editor responsive, ensuring it utilizes as much of your screen as possible. This improvement allows for a more comfortable and efficient editing experience.
To guarantee high-quality configurations, we've tightened the rules to only allow correct TypeScript. This enhancement ensures that you won't accidentally store incorrect configs, providing peace of mind and a more reliable user experience.
For a more streamlined editing process, you can now submit your changes using CMD+Enter. This keyboard shortcut makes saving your work quicker and more convenient.