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

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

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.

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.

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:

You can now create, edit and delete cache rules right from your dashboard. Head to the "Cache" tab of your service and click on the "Create new rule" button to open the form to create a new rule:

You can also edit and delete existing rules by clicking on them.

As of v1.0.0 of the CLI you can push individual fields with the graphcdn push command! For example, to push a schema change run:

graphcdn push schema

This will only update the schema of your service. You can do the same thing with almost any property of your graphcdn.yml, for example:

graphcdn push rules

or

graphcdn push headers

When you run the graphcdn push command we immediately validate your configuration file to ensure it is correctly formatted.

However, the validation error messages were not as helpful as they should be. We have overhauled them in the latest release of the CLI (v0.4.3) to make sure they precisely explain the issue(s):

$ graphcdn push
Error:  Invalid graphcdn.yml:
- schema: Required
- defaultCacheControl.scope: Expected string, received number

Install the latest version of the CLI by running the npm install graphcdn@latest command in your project's directory.

Our gateway wasn't built with very large (megabytes) responses in mind, and thus would sometimes hang or even crash when lots of data was being sent through it.

As of today, we have added support for responses in the dozens of megabytes. We've also added a pass-through for responses that are too large for us to handle, so even if you're above our gateway's limit your users won't notice a thing.