- [Support for silverstripe/graphql v4](#graphql-v4)
## New features
### Support for silverstripe/graphql v4 {#graphql-v4}
The [silverstripe/graphql](http://github.com/silverstripe/silverstripe-graphql/issues) 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](https://github.com/silverstripe/silverstripe-framework/issues/8824) and [pull request](https://github.com/silverstripe/silverstripe-graphql/pulls)).
The resulting`silverstripe/graphql:^4` release is currently in a alpha stage.
We encourage everyone to get started, read our new [GraphQL documentation](https://docs.silverstripe.org/en/4/developer_guides/graphql/),
provide [feedback](https://github.com/silverstripe/silverstripe-graphql/issues) 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.
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](https://blog.packagist.com/composer-2-0-is-now-available/#3-backwards-compatibility-breaks) 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.
