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. 

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.

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.

(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!

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.

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!

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.

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.

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

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

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

With version 1.3.0 of the GraphCDN CLI we released a new feature in beta that allows you to spin up a GraphCDN service for your local development environment.

Over the last couple of weeks, we noticed that it was quite hard to "just try" GraphCDN. You typically had to target a production instance of your GraphQL backend, or at least an instance exposed to the internet. With the new serve command you can point GraphCDN at a locally running GraphQL API and use it in your development environment.

To give this a try you'll need to have an account with GraphCDN. If you're new, please sign up first and then run graphcdn login to sign in to your account.

Next, you'll either need to pull your graphcdn.yml configuration (via the graphcdn pull command) or create a scaffolding configuration that looks like this:

# Skeleton graphcdn.yml
name: local-dev
app: local-dev
schema: http://graphql.local
originUrl: http://graphql.local

Also, make sure your development GraphQL server is up and running and accepting requests.

Once you're ready, you can create the development environment via the following command:

graphcdn serve --backend-port  --service 

As service name use the same value provided in your graphcdn.yml file. In the example configuration above we'd use local-dev as the service name.

The serve command supports the following options

• --backend-port, the port on your local host your GraphQL server is running on
• --service, the name of the service if not specified in the graphcdn.yml file
• --serve-port, the port you want to have the GraphCDN environment available on, defaults to the first free port greater than 3000 (Optional)
• --watch, whether to watch the graphcdn.yml file for changes.
• --path, the path your GraphQL API is available on, e.g. /graphql

This will make debugging your GraphCDN setups, as well as giving GraphCDN a try, a lot easier. Let us know what you think and if you have questions, please reach out to us via support@graphcdn.io.

We have rolled out initial support for GraphQL Query Batching which means an array of queries can be sent all at once.

A usual GraphQL JSON payload looks like this:

{ "query": "{ roadster { name } }" }

With query batching you now can send this:

[
  { "query": "{ roadster { name } }" },
  { "query": "{ launchesPast(limit: 5) { mission_name } }" }
]

Batched queries are analyzed at our edge locations, split into individual requests, and then handled concurrently by either the cache (if already cached) or the GraphQL backend servers configured for your service. The GraphCDN service will wait until all requests have been answered, merge the individual responses, and send them to the client.

If you are using batched queries, there is nothing for you to configure or set up. Any requests that would have been passed through to your backend servers are now being analyzed and cached by the CDN. The same cache rules and scope that apply you have already configured apply to batched queries as well.

If you have any questions or are running into issues with batched queries, please let us know at support@graphcdn.io (or via the handy chat button on your dashboard).

To make sure you stay on top of your servers, GraphCDN will now automatically send you alerts via email for any 5xx responses from your origin. For example, if your server were overloaded you might get an email like this:

----

Your service just received 7 errors in the last 60 seconds. Here is one example error:

Service Unavailable, No server is available to handle this request

You can see all the details on your dashboard.

----

We plan to expand this and make it configurable in the future, but for now this will at least let you know when something is going very wrong with your server.

At its core, the GraphCDN Edge Cache analyses GraphQL queries and computes the correct Cache-Control header for them based on your rules.

However, some origin's respond with a Cache-Control: private, no-store header by default, which would cause the Edge Cache to not cache anything, ever. To combat that and make sure the GraphCDN Edge Cache caches as expected we ignore the origin Cache-Control header by default. 

However, in some edge cases you might actually want the cache to respect it, so there is now a setting to disable "Ignore origin Cache-Control header" in the "Advanced" section of the "Cache" tab: