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.

Additional request metadata

We also exposed more metadata fields from the request. Now you’ll be able to see:

• The raw user agent string
• HTTP status code
• Original and cached response latency (this allows you to see how much faster cached responses are).
• Scopes
• Types and Fields

More context on Non-GraphQL requests and non-cacheable operations

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.

🧠 Intelligent Diffing Algorithm

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.

🔐 Unquoted JSON Keys

To prevent crashes in certain cases, we now unquote JSON keys in the config. This simple change will significantly improve the editor's stability.

📏 Responsive Config Editor

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.

🛡️ Enhanced TypeScript Validation

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.

⌨️ Submit Changes with CMD+Enter

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.

• We improved the font-loading performance in the dashboard by pre-loading and removing some unused weights.
• Additionally, we tuned a11y by adding alt-texts to all images, and buttons and added link names.
• And as always, speeding up an app can be improved by fetching the data quicker!
• We improved our fetching strategy from the metrics page as well!

Our team has worked hard to make cache purging more usable.

One-Click Cache Purging

• We've introduced a "Purge Cache" button that allows you to easily clear the entire cache with a single click. No more tedious cache management - just click, and you're done!
  

Purging API Endpoint

• To make our caching solution even more developer-friendly, we've added a purging API endpoint. This addition makes it more accessible and convenient for you to integrate cache purging into your stack.

Linked Affected Types in Purging View

• To provide better context and make navigation easier, we now link the affected types in the purging view to the related page displaying the type. This enhancement will save you time and help you better understand your cache structure.

Direct Purge from Operations and Schema Pages

• We've added "Purge" buttons to both the Operations and Schema pages, so you can directly access the purging view from these locations. This streamlined approach will make it even easier to manage your cache and keep your data fresh.
  

We're excited to announce an improvement to the ignoreOriginCacheControl configuration option, giving you even more control over cache behavior customization!

Previously, when this option was set to false, it mainly prevented the deletion of the cache control received from your origin. However, it would still be overridden by the rules applied based on your results.

Now, setting this option to false treats the cache-control header from your origin as an additional cache rule. The system first calculates the cache-control from your stellate-config and then compares it to the cache-control header received from your origin. If your cache-control permits a shared cache, we consider the s-maxage, max-age, and stale-while-revalidate directives and choose the lowest value to optimize caching.

Furthermore, when non-cacheable directives like private, no-store, or no-cache are encountered, we will set the max-age to 0 and treat it as a cache pass.

Rest assured, if you have an undefined or truthy setting, there will be no changes.

This enhancement allows you to overwrite the cache-control header correctly, providing greater flexibility in customizing cache behavior. We hope you find this update helpful!

Based on your awesome feedback, we did a bunch of improvements on our metrics page! These improvements are supporting a range of more use-cases, such as improved debugging of latency, cache hits and scopes!

🔢 Total count and cache hit rate on operations page

On the operations page, we’re now showing the total count per operation. This is useful to know what your most requested operations are, so you have a starting point what to optimize first.

👥 Distinct IPs

On the schema, operations, and users pages, we’re now showing the unique users.

🔍 Filtering by Scopes

↕️ Sorting by latency

💅  Service Config Formatting

• We improved how your service config is shown in the dashboard. We’re now formatting it with singles quotes and trailing commas.

📚 Importing functions from the stellate package

You can now import functions from the stellate package in the UI, fully type safe 🎉 

More Fixes

• The CLI is now printing a correct config for the stellate init command.
• The dashboard now shows the billing portal for failed payments.
• Links to individual Canny posts are fixed.
• Our Slack integration authentication had a hick up, which we now fixed.
• We fixed some edge cases in the configuration function serialization, which caused errors or bundled them into a faulty code.
• The rules in the configuration now support null and undefined rules. This is particularly helpful if you want to calculate the rules programmatically.
• Ensure that all responses are purgeable, even in cases where we run a pass-through (bail), with the origin setting a cache control header.

We've just added Rate Limiting for your GraphQL API. We are excited to announce the Beta release of our latest feature. With Rate Limiting we want to help you to protect your GraphQL API from bots, hackers, and SLA violations by rate limiting specific GraphQL operations. 

Through our conversations with hundreds of companies using GraphQL in production, we’ve learned about some common pain points:

1. Bots spamming their addToCart mutation whenever they drop new limited edition products
2. Hackers sending lots of requests to the login mutation, trying to crack their users’ passwords
3. Consumers exceeding SLAs they’ve signed that limit the number of times they can request certain data

The solution for all of these is to rate limit the number of calls any single consumer can make. For example, only allowing two login or addToCart mutations from a single actor every ten seconds. 

Check out the docs and learn how to use Rate Limiting to protect your GraphQL API. While still in Beta, keep an eye on the limitations.

Join the channel #rate-limiting for feedback and support on our Discord server!