You can read more about the project and what it means for you in our docs. But in short, these new improvements lay the foundation for:

• A more reliable platform with fewer dependencies
• Better performance with even lower latencies
• Higher cache hit rates through new features

Stay tuned for the announcements ahead as we leverage this new foundation to improve the platform for you.

Please migrate your services by September 15th

It’s our responsibility to keep your services running smoothly, and we thank you for your trust. To honor that trust, we’ve done our best to make this transition as easy as possible and given you control over when to migrate your production traffic.

As of today, you can go to the settings for any of your existing services and toggle the new system on or off.

Services created from the 1st of August onwards automatically use the new system and can’t switch back to the legacy infrastructure.

Our support team is here for any questions you have before or after the migration. We’ve created a documentation page about the migration to make the transition as easy as possible.

This transition period begins today and allows your team 6 weeks to migrate proactively before the deadline on September 15th, when our team will be migrating all services. If you can not make the migration by that deadline and have concerns about your service being switched over, please reach out to our support team so we can work out a suitable migration path together.

Behavior changes

We’ve made one potentially breaking change which all service owners should consider the implications of before migrating. If you limit the number of aliases allowed in queries or the overall byte size of the query, this is likely a breaking change for your use case. We advise that you raise the limits and test your application in staging before migrating your production service.

• [Major] __typename insertions replaced with __stellate__internal__typename: __typename

We’ve also introduced a few minor changes, which should have no functional impact on your services. You can read all about them in our extensive migration documentation.

• [Patch] Support for 64-bit precision for both integer and floating point numbers
• [Patch] APQs will need to be re-fetched
• [Patch] We no longer serialize surrogate keys that are objects or arrays
• [Patch] Improved bot protection
• [Patch] More consistent handling of new lines in error cases
• [Patch] Order of data, errors, and extensions response fields

We hope that you will find this a smooth transition, and if you have any questions about or during this process, our support team is available for you.