We're excited to announce a new feature that enables purging by a specific scope value, designed for users who utilize Stellate in a multi-tenant fashion.

This feature allows for more granular cache purging while maintaining overall performance and ease of use.

It has been requested by a bunch of you on our Stellate Feedback board: https://stellate.co/app/feedback/p/purge-by-scope-value

Read more in the docs

We introduce two new mutations in the purging API to make this possible.

You can purge the cache for regular scopes as well as JWT-scopes every time we encounter a scope we'll create a surrogate key for it.

_purgeScope

To purge all queries that are cached with a certain scope, you can now use _purgeScope

_purgeJWTScope

To purge all queries that are cached with a certain JWT scope, use _purgeJWTScope.

Check out the docs

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! 

We are excited to announce that our GraphQL API is now open for anyone to use! 🎉

GraphQL gives a lot of power to developers through flexibility, which is why many of us love it. That flexibility has the downside of making it harder to open up GraphQL APIs, with authorization, schema evolution and security being non-trivial concerns.

However, opening up your API and enabling third-party developers to integrate with your systems is a powerful way to create business value. That’s why our current mission to make open GraphQL APIs ubiquitous, and our first step towards that is opening up our own GraphQL API to allow anyone to build an integration with our platform.

If your company is using GraphQL and you’re also thinking about opening up your GraphQL API, apply to be a part of our Open GraphQL API Pilot Program, where our GraphQL experts help companies successfully open up their GraphQL APIs.

Learn more in the announcement blog post and check out the docs to get started!

Team

• Dominic Petrick, who previously worked on the Prisma Query Engine, has joined us as a full-time Rust developer

Changes

• All Stellate endpoints now show the new GraphiQL v2 🎉 To see an example, visit graph.stellate.co 
  • If you're not seeing this at your Stellate service's endpoint, make sure to enable introspection and set enablePlayground: true
• Changelog inception: the changelog has been embedded in the dashboard sidebar so you all can see this
• We now allow overwriting enablePlayground within environments
• We added two new mutations to our open API:
  • applyForJob - apply to a job at Stellate through a GraphQL mutation 🤯
  • submitApiFeedback - GraphQL inception: making it possible to give feedback for our new API through our API 😍

Fixes

• Fixed a rare infinite loop when closing modals, which sometimes triggered an infinite toast popup loop
• Incorrect variables are now handled gracefully in GraphiQL
• Fixed Intercom authentication so we know it's you reaching out with questions
• Fixed an issue with upgrading to the business plan
• Fixed showing empty cards in the service history
• Fixed the error query and country not showing
• Ensured the cache state & response timing is always visible in GraphiQL
• Fixed the Purging IDE button and shared metrics layout

Last week, we announced five new major features! Let’s recap.

A whole new dashboard

You gave us the feedback, we listened! We shipped a whole new dashboard with new metrics, purging history and much more. Check it out at stellate.co/app

New GraphQL Metrics

With the new dashboard, we released brand-new GraphQL Metrics that allow you to slice and dice aggregate traffic data, understand individual requests in full context, and monitor performance and errors.

Purging Analytics

The new purging analytics allow you to have full visibility into your cache's activity, which allows you to optimize your cache hit rate and have the confidence that no stale data is served to your users.

New GraphiQL integration

We integrated a GraphQL IDE into our new dashboard to allow users to test queries against their API quickly. The IDE is based on the upcoming new version of GraphiQL, which is more extensible and customizable.

Universal Configuration-As-Code

The new Stellate dashboard includes a code editor for "universal configuration-as-code." This allows for better knowledge transfer between UI and terminal, instant feature parity and faster shipping, and DRY code reuse across environments. We are exploring ways to further utilize UI to enhance the experience with the new TypeScript-based configuration.

Since then, we got a lot of great feedback and worked on the following fixes:

Changes

• Introduce pagination for the Service History
• Show config diff in --dry command

Fixes

• Fix the chat bubble in the dashboard
• Fix the top navigation moving and shifting when activating different items
• Fix tracking the PASS response state and visualizing it in GraphiQL
• More robust config validation in the UI
• Improve dashboard UX by adding stand-in values for the navigation
• Fix submitting the query depth limit
• Replace @monaco-editor/react with our own implementation, which increases the reliability and performance of the code editor in the dashboard

Today is National Pizza Party Day, and we have a couple of improvements to release.

New

* Cloudflares CF-IPCountry header is now getting passed through to backend services. Since we are using Cloudflare as well, some headers usually set by Cloudflare will get overwritten with GraphCDN-specific values. If you run Cloudflare in front of GraphCDN and need access to those headers, let us know and we'll take a look if/how we can pass through the original values.

* GraphCDN joined Stripes Climate program and donates 1% of our revenue to carbon removal. See https://climate.stripe.com/wMbSdD for more information

Fixed

* Weekly Digest emails sometimes got stuck/congested. We fixed that bug and those digests are now getting delivered reliably.

The release included further under-the-hood improvements and preparations for soon-to-be-launched features. Stay tuned for those, you are going to 😍 them.

We're excited to announce a new Wordpress plugin that makes using GraphCDN with WPGraphQL a breeze.

The plugin takes care of invalidating the cache for any entities you update in your Wordpress installation, works with custom post types as well as taxonomies and allows you to focus on your content and not worry about your GraphCDN setup.

See https://docs.graphcdn.io/docs/graphcdn-wordpress-plugin for more information, as well as installation instructions. And don't hesitate to reach out via support@graphcdn.io or the in-app messenger if you have any questions at all.

We're happy to release the new graphcdn check CLI subcommand.

Based on the analytics data GraphCDN collects for your service, we check that any breaking changes you make to your GraphQL API will not affect your users. See https://graphcdn.io/blog/announcing-graphcdn-check for the announcement blog post and https://docs.graphcdn.io/docs/cli#check for the documentation.

The next step? Opening a PR on your CI/CD workflow to call graphcdn check as part of your pipelines.

The GraphCDN team spent the last week in Lisbon, Portugal at an amazing onsite. (Since we are a distributed company, we're actually "on-site" when we're all together. 😊) Other than getting to know each one of us better, and working hard on the vision and mission for our company, we also shipped some improvements, fixes, and new features.

New

• We have a new field called servicesList on the organization type, which allows you to paginate/filter through all services owned by an organization. This implements the relay-pagination spec.
• POST requests with an empty body are now blocked at the edge.

Improved

• The Forwarded headers are now appended rather than replaced
• Requests are retried at most once to not overload your backend services.

Fixed

• We have fixed the Slack channel selector, which was not working for Slack workspaces with more than 1000 channels. We will now load all non-archived channels when loading the page. Unfortunately Slack does not implement filtering via their API 😅, which makes our UI and background logic a slight bit more complicated.
• We now make a better attempt at removing the TLS subscription when removing a custom domain from your service.
• We have fixed an issue where we would cache empty array root-fields