One month ago we launched Custom Attributes in Public Beta. Since then we have seen great adoption and got great user feedback on the feature. Today we're announcing that Custom Attributes are moving out of the Beta phase and into General Availability! There are no changes to the feature, so you don't need to adapt anything if you already started using the feature in Beta.

We have closely observed how our customers use Custom Attributes to personalize and get the most out of their GraphQL Metrics. Here are some of these use cases.

Track the clients that are using your GraphQL API

If you have multiple clients that consume your GraphQL API, like web and mobile applications, it's crucial to know which client is sending what requests. We have seen customers setting up Custom Attributes that track the kind and version of their clients using HTTP headers.

Identify requests from individual users

Many GraphQL APIs require some kind of token for authentication. JWTs are a common standard used across the web, and they already contain information about the identity of the user it belongs to. We have seen Custom Attributes being set up to store user identifiers from the JWT payload to enable tracking the interactions of individual users with their GraphQL API.

Get Custom Attribute metrics into your own systems

Having Custom Attributes in your Stellate GraphQL Metrics is great, but we saw cases where users could only store anonymous access tokens instead of human-readable identifiers. With just that, it would be a lot of manual work to correlate GraphQL Metrics with data from other systems.

To help automate this process, we also expose Custom Attributes (and also lots of other parts of our GraphQL Metrics) via our Public GraphQL API. This enabled users to periodically pull the data from our system and integrate it into their own data lakes.

There's more!

This is just a short list of all the cool customizations you can do to your GraphQL Metrics with Custom Attributes. We're excited to see even more use cases from our users. Check out our documentation today to get started with Custom Attributes!

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.

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.

We' ve just released the GraphQL Developer Portal! We'd love to share something we've been working on with you, which is a way for you to generate a Developer Portal for your stellate API.

When leveraging this new feature we will create a new web-application that is located at `<serviceName>.stellate.io`, you can configure the branding, links, ... of this app. Here you can guide people so they can get to know your API.

If your origin API does not leverage authentication the developer portal can facilitate that by toggling `auth` on. This will allow consumers of your API to log in and generate API-tokens which you will be able to filter on in your stellate metrics.

Try it out today by going to your service-settings and choosing developer portal or adding `devPortal: { enabled: true }` to your config.

Do you have more ideas for the developer portal? Suggest them or upvote what others have suggested.

We're excited to announce the public beta release of Custom Attributes for Stellate's GraphQL Metrics! This new feature will give you even more control and insights into your GraphQL API usage.

New Features

- Custom Attributes: Define up to five Custom Attributes per Stellate service to track additional data points with every GraphQL request. You can use HTTP headers, cookie values, or JWT claims as Custom Attributes.

- JWT Claim Support: Extract specific JWT claims for Custom Attributes. Supported algorithms include HS256, HS384, HS512, RS256, RS384, RS512, ES256, ES256k, ES384, RSA-PSS (PS256, PS384, PS512), and EdDSA.

- Nested Claims: Access nested JWT claims using lodash-like dotpath-notation.

- Filter Metrics: Filter your GraphQL Metrics down to specific users or groups using Custom Attributes.

- Multitenancy Support: Track metrics for individual tenants in multi-tenant applications by storing tenant identifiers as Custom Attributes.

Limitations

- You can define at most five Custom Attributes for each Stellate service.

- Custom Attribute values are limited to a maximum of 256 characters in length. Longer values will be truncated.

- Data persistence: Stored values will remain even after removing a Custom Attribute from the Stellate Configuration. Currently, there is no way to customize this behavior or remove stored data.

Documentation and Demo

- Custom Attributes Documentation

- Demo Video on Using Custom Attributes

We look forward to your feedback and can't wait to see how you leverage Custom Attributes in your projects!

🚫 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.