Stellate Product Updates logo
Back to Homepage Subscribe to Updates

Product Updates

See the latest new features, improvements, and product updates

Labels

  • All Posts
  • Fix
  • Announcement
  • Improvement
  • graph api
  • feature

Jump to Month

  • December 2023
  • September 2023
  • August 2023
  • July 2023
  • June 2023
  • May 2023
  • April 2023
  • March 2023
  • January 2023
  • September 2022
  • August 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • January 2022
  • December 2021
  • November 2021
  • October 2021
  • September 2021
  • June 2021
  • May 2021
  • April 2021
  • March 2021
  • February 2021
Improvement
a year ago

Improving the Config Impact Preview

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.

Avatar of authorDaniel Lehr
Announcementfeature
a year ago

Change your GraphiQL playground title

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.

Avatar of authorJovi De Croock
Improvement
a year ago

Preview the impact of new or updated caching rules on your existing operations

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.


Avatar of authorBogdan Soare
Improvement
a year ago

New and improved architecture 🎉

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:

  • A more reliable platform with fewer dependencies
  • Better performance with even lower latencies
  • Higher cache hit rates through new features

Stay tuned for the announcements ahead as we leverage this new foundation to improve the platform for you.

Please migrate your services by September 15th

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.

Behavior changes

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.

  • [Major] __typename insertions replaced with __stellate__internal__typename: __typename

We’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.

  • [Patch] Support for 64-bit precision for both integer and floating point numbers
  • [Patch] APQs will need to be re-fetched
  • [Patch] We no longer serialize surrogate keys that are objects or arrays
  • [Patch] Improved bot protection
  • [Patch] More consistent handling of new lines in error cases
  • [Patch] Order of data, errors, and extensions response fields

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

Avatar of authorMax Stoiber
Improvement
a year ago

Enhancing Our Cache Configuration for Non-Cacheable Types

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.

Avatar of authorThomas Heyenbrock
Improvement
a year ago

Visualize how config changes impacts your cache hit rate

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.

Avatar of authorVictor Tortolero
a year ago

Update to Cache Hit Rate calculation

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.

Avatar of authorVictor Tortolero
a year ago

Cache Optimization Dashboard

We're excited to announce the launch of our new Caching Metrics page, a powerful tool that provides in-depth insights and opportunities for improving your caching strategies. The Caching Metrics page introduces two new chart types:

  • Cache Hit Rate (CHR) over time: You will be able to see the evolution of CHR in your service and compare it with the Max CHR. This will enable you to understand how CHR changes after a configuration change or a schema change.
  • Uncached bandwidth: Ever wondered how much bandwidth is prevented from going to your backend thanks to using Stellate? This metric will give you that info.

In addition to the above, we've also introduced the Caching Improvement Opportunities table, which will allow you to understand your API operations and identify what traffic types you could potentially cache next, along with their potential impact on your overall CHR.

To illustrate, consider the getAllBlogCollections operation in the image below. Its current CHR stands at 2.8%, but the Max CHR is as high as 89.6%. By optimizing your service to cache this operation and move it closer to the Max CHR, you could anticipate an overall CHR improvement of approximately 2.4%.

These new functionalities underscore our commitment to assist you in enhancing your caching performance. We look forward to you experimenting with the Caching Metrics page and improving your CHR! You can access this page under the Metrics section, available now to all Stellate services.

Avatar of authorVictor Tortolero
a year ago

Custom Attributes Are Now Generally Available

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!

Avatar of authorThomas Heyenbrock
feature
a year ago

Filtering Metrics by Date Range

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.



Avatar of authorDaniel Lehr