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
Announcement
3 years ago

Purge by query root fields

If you want to purge specific results based on fields and arguments passed to your queries, you can use the _purgeQueryField(fields: [QueryFieldInput!]!) mutation.

The QueryFieldInput argument will be an enum based on your schema if you pushed your schema to GraphCDN (or have introspection enabled), or a string if GraphCDN doesn't have access to your schema.

As an example, let's say you have the following query as part of your application:

{
  package(name: "@urql/core") {
    __typname
    name
  }
}

You can then target the package field and purge the above result with the following mutation.

mutation {
  _purgeQueryField(fields: [
    {
      name: "package",
      args: { name: "@urql/core" }
    }
  ])
}

If you pushed your schema to GraphCDN, you could also use more specific mutations based on your schema definition. For example, you would also be able to use the following mutation.

mutation {
  purgeQuery_package(args: [{ name: "@urql/core }])
}

And you can, of course, pass in those arguments via variables as well.

Avatar of authorMarko Locher
Improvement
3 years ago

Increased Cache Limits

Up to now, GraphCDN could cache GraphQL responses up to 2MB in size. If the response size was larger than this, the response could not be stored in the cache, and any future requests would be passed on to your backend service.

We are happy to announce that we could bump this limit and can now cache responses up to 10MB in size.

Avatar of authorMarko Locher
Announcement
3 years ago

Define headers to bypass the GraphCDN edge cache

You can now define a set of request headers that will cause GraphCDN to bypass the cache and pass the request on to your origin. Any request you send that includes one of those headers (e.g. a x-preview-token header with any value) will not be cached.

You will see a new option called Bypass Headers in the cache configuration on your service dashboard.


However, you can also specify those headers via the graphcdn.yml in a new bypassCacheHeaders section.

name: my-app
schema: https://end.point
originUrl: https://end.point
bypassCacheHeaders:
    - name: x-preview-token
    - name: some-other-token
...

Common use cases for this feature are preview modes for e.g. a headless CMS or specific queries where you always want to get the latest data.

See https://docs.graphcdn.io/docs/bypass-headers for our documentation of this feature.

Avatar of authorMarko Locher
Announcement
3 years ago

Double your free requests with the brand-new "Powered by GraphCDN" badge

If you have this shiny "Powered by GraphCDN" badge in the footer of your website, we'll double your free monthly requests to 10M!

Copy-and-paste this HTML code into your website's footer, email us a link, and we'll unlock the extended free plan for you:


  Powered by GraphCDN
Avatar of authorMarko Locher
Announcement
3 years ago

New identity provider: GitLab

We now support signing up for GraphCDN, as well as signing in, via GitLab.com. We do not currently support self-hosted GitLab instances.

If there are other identity providers you are looking for, please let us know!

Avatar of authorMarko Locher
Improvement
3 years ago

Delete custom domains

GraphCDN long supported running your service on a custom DNS name provided by you.

However, until now you weren't able to remove a custom domain once it was set and always had to reach out to our support team for changes.

With the latest improvements, you can now delete and reconfigure custom domain names via the dashboard.


Avatar of authorMarko Locher
Announcement
3 years ago

Automatic Persisted Queries (APQ)

We recently shipped support for automatic persisted queries (or APQ for short), which can help drastically reduce the size of your GraphQL payloads sent from your clients to GraphCDN edge locations.

Here is an example request using the { __typename } query. The initial request would look like the following curl command:

curl -g -X POST -H "Content-Type: application/json" \
  -d '{"query": "{__typename}", "extensions": {"persistedQuery": {"version":1, "sha256Hash": "ecf4edb46db40b5132295c0291d62fb65d6759a9eedfa4d5d612dd5ec54a6b38"}}}' \
  https://spacex-api.graphcdn.app

Subsequent requests for the same query would only need to use the hash of the operation, dropping the query key completely:

curl -g -X POST -H "Content-Type: application/json" \
  -d '{"extensions": {"persistedQuery":{"version":1,"sha256Hash": "ecf4edb46db40b5132295c0291d62fb65d6759a9eedfa4d5d612dd5ec54a6b38"}}}' \
  https://spacex-api.graphcdn.app

This example uses a quite small query, which doesn't show the full impact APQs can have. However, keep in mind that the query can be of arbitrary length, whereas the sha256 hash will always have a constant length.

You can read more about Automatic Persisted Queries on the Apollo Documentation at https://www.apollographql.com/docs/apollo-server/performance/apq/ (among other pages). And as with all our changes, we're always looking for your feedback. So let us know if you think we can improve support for APQs via support@graphcdn.io. 

Avatar of authorMarko Locher
Announcement
3 years ago

Retries

GraphCDN now supports retrying some failed requests right from the edge cache. Instead of your application having to trigger a second network request, we can take care of that.

Retries are available for two types of errors, so-called Network Errors, i.e. any responses with an HTTP status code of 502, 503, 504, or in the 520 to 527 range. For those errors (and if HTTP status codes are used semantically correct) a retry might return a valid response as the underlying error condition might have been resolved. 

The second category is Server Errors, which includes all other HTTP/5xx status codes. In those cases, the chance of resolving the issue with a simple retry is lower, but it might still be a temporary issue and we want to give you the chance to decide whether to try again or not.

By default, any GraphCDN service is configured to not retry any requests. If you want to enable retries you need to set this up for each of your services.

To enable retries, configure them in your graphcdn.yml configuration file and push the new configuration to your service via graphcdn push

name: my-app-with-retries
# (your other GraphCDN configuration)
# ...
retries:
  networkErrors:
    isEnabled: true
    whenGraphQLResponse: false
  serverErrors:
    isEnabled: false

The whenGraphQLResponse option shown above indicates whether you want to retry a request even if the response includes a valid GraphQL payload. By default, any requests containing a valid GraphQL response won't be retried.

Avatar of authorMarko Locher
Announcement
3 years ago

[BETA] Slack Integration for Alerts

We continue to extend and improve our Alerts system. In addition to alerts via email, you can now also connect GraphCDN to your Slack workspace and have alerts show up in your Slack channels.

To use Slack, you'll first need to head over the to the _Integrations_ page for your organization (which is also new) and install the GraphCDN Slack application.

Once Slack is connected, you can select Slack when creating or editing an alert, and then select the Slack channel you'd like to send the alert to.

Screen Shot 2021-11-03 at 2

(As you can see, Max, one of our founders, is blown away by the new feature.)

As with all alerts you can fine-tune when notifications should be sent, and if you alert on GraphQL errors you can also filter based on the error code, or the path.

Which other systems would you like to use for Alerts? We have heard about PagerDuty from a couple of you, but what else is missing? And which other improvements would you like us to make with alerts? Let us know at support@graphcdn.io!

Avatar of authorMarko Locher
Announcement
3 years ago

[BETA] Filters for GraphQL Alerts

Hot on the heels of last week's release of configurable alerts we published another feature for your alerts! You can now configure new alerts to look for specific GraphQL Errors with message and code filtering and only get alerted for specific errors.

A new set of controls allow you to either include or exclude any errors the CDN has seen at least once, as can be seen in the below screenshot from a sample project.

Creating an alert for GraphQL Errors

As always, we'd love to get your feedback on what you'd like to see next with alerts, what's already useful, and what you think we could improve. Don't hesitate to reach out via the embedded messenger, or support@graphcdn.io!

Avatar of authorMarko Locher