Define headers to bypass the GraphCDN edge cache
new
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.
Screen Shot 2022-01-11 at 16
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.
Double your free requests with the brand-new "Powered by GraphCDN" badge
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:
<a href="https://graphcdn.io">
<img src="https://graphcdn.io/badge.svg" alt="Powered by GraphCDN" />
</a>
New identity provider: GitLab
new
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!
Delete custom domains
improved
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.
Automatic Persisted Queries (APQ)
new
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.
new
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.
[BETA] Slack Integration for Alerts
new
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!
[BETA] Filters for GraphQL Alerts
new
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!
[BETA] Configurable Alerts
new
GraphCDN has been sending email alerts whenever we saw an HTTP 5xx error for a couple of months now, however, those alerts were not configurable.
We just published a
new "Alerts" module
as a beta release that allows you to configure when to send an alert based on certain criteria, as well as who to send those alerts to. At the moment alerts are limited to email, however, we will extend this system with other communication channels in the future.
Screen Shot 2021-10-21 at 12
You'll find the
Alerts
as a new tab in your service configuration, and by default, we configured the same 3 alerts for HTTP/4xx, HTTP/5xx, and GraphQL errors that we have used in the past.
However, you can now delete those alerts and create your own set with the specific configuration that you and your team actually care about.
Screen Shot 2021-10-21 at 1
Each alert allows you to specify an interval as well as an error condition that needs to apply, configure a name and recipients (either from your existing GraphCDN team or a specific alerting email address you might already be using).
Screen Shot 2021-10-21 at 1
The alert emails themselves are quite simple. They include the service name and alert conditions you have configured, as well as the error message from the last error and a link to your service's dashboard.
And, to make sure you only get the alerts you care about, you can unsubscribe (or edit the alert) right from the email itself!
As always, we're looking for your feedback. What else would you like to see to make alerting more useful for you and your team? Which other notification channels do you care about? Let us know via email at support@graphcdn.io
Signup & Login via Email
new
You can now sign up for GraphCDN via email. Simply head over to the Signup page, enter your email and you're good to go.
We will send you a magic link to the email address you entered that will sign you up for GraphCDN, and you can continue with the onboarding experience once you've opened that link.
In case an account for that email is already registered you will instead get a magic link logging you into your already existing account.
As always, we'd be happy to hear your feedback, or answer any questions you might have. Please let us know via the integrated messenger button or support@graphcdn.io
Load More