3.2 KiB
4.8.0 (Unreleased)
Overview
New features
Support for silverstripe/graphql v4
The silverstripe/graphql module to drive various parts of the CMS UI, as well as building your own GraphQL APIs in Silverstripe projects.
The CMS currently ships with silverstripe/graphql:^3, which is stable but slow for larger schemas.
The module was rewritten from scratch with performance in mind
(see goals and pull request).
The resultingsilverstripe/graphql:^4 release is currently in a alpha stage.
We encourage everyone to get started, read our new GraphQL documentation,
provide feedback and help us stabilise the module.
In order to facilitate the new module release, most GraphQL helper classes to drive the CMS UI
have been marked as deprecated, and moved to GraphQL/_legacy folders within core modules.
The GraphQL schema under admin/graphql has been altered slightly to enable forwards compability,
with lower-camelcase field names, and a different filter argument structure.
In the unlikely case that you are relying on those classes or queries directly,
consider upgrading to silverstripe/graphql:^4.
Your own GraphQL schemas outside of admin/graphql should not be affected by the changes
if you choose to stay on silverstripe/graphql:^3 for the time being.
We are planning to require the use of silverstripe/graphql:^4 in a future CMS 4.x release.
GraphQL 3 code moved to _legacy folder
You will notice that many of the core modules now have a _legacy directory in their root.
This is a temporary fix that we have applied to satisfy the competing interests of semver and
PSR-4 autoloading.
Because the semver contract precludes changing the fully-qualified names of any classes,
we need to keep GraphQL 3 code untouched. But GraphQL 4 code often contains classes of similar
or identical names, e.g. "ReadFilesResolver", or something to that effect. Further, this
backward compatibility creates a common demand for the canonical namespace "GraphQL.", e.g.
SilverStripe\AssetAdmin\GraphQL. It didn't seem appropriate to put old code in the "GraphQL"
space, and new code in a less obvious place, like SilverStripe\AssetAdmin\GraphQL4.
A simple fix would have been to stuff all the GraphQL 3 code into code/GraphQL/_legacy and use classmap to shim the PSR-4 autoloader, but this is no longer supported in Composer 2.0.
Thus, we ended up with the "least bad" solution, which was to create a parallel path resolution
for GraphQL 3 code in the _legacy folder, alongside code/ / src/.
It is likely that in the future, we will mandate the use of GraphQL 4 in Silverstripe CMS, and
remove this shim. We expect this happen within just one minor release, making _legacy/ a very short-lived workaround.