I'm not currently using graphQL as an API, but this looks really good to me. Having a separate dev/… endpoint for every schema seems quite bad though, given how many times an error gets posted around here, just because the developer forgot do to dev/build

Everyone: we really need your input on this one, as it’s a crucial step to making this module scalable. I know it’s a lot to read through, but even just a general reaction to the new developer experience would be useful.

Thanks, @chillu. I’ll add those bullet points to the PR and update the RFC thread.

@unclecheese has made some awesome progress on speeding up GraphQL execution. It’s currently in peer review, and we’re looking for feedback. The RFC description at https://github.com/silverstripe/silverstripe-graphql/issues/192 is partially outdated, since we’ve pivoted from serialisation to code generation. The pull request itself has an up-to-date description: https://github.com/silverstripe/silverstripe-graphql/pull/202.

This will go into a new major release of silverstripe/graphql, but needs to be included in SilverStripe 4.x to be useful. On a high level, it introduces a few important changes:

  • Mandatory schema cache generation step for developers (which can take 30s+)
  • Remove direct references to webonyx/graphql-php types. We’re quite far away from how that library expects you to define types now, so the partial coupling was getting in the way
  • No support for resolvers through closures (since there’s no decent way to pass through the closed over values into the generated PHP)

This is the result of more about two weeks of @unclecheese’s excellent coding, plus hours of conversations between the two of us along the way. Major milestone for the module, and SilverStripe’s future as a Decoupled CMS. But it doesn’t come “for free”, hence asking for feedback.

Attachments:
#192 RFC: Make schema serialisable and cachable
#192 RFC: Make schema serialisable and cachable
#202 WIP: Schema caching
💯 (2)

And ideally, Fluent would hook into an API that allows it to modify CRUD args

You'll need a custom resolver and a onBeforeAddToManager hook in an extension

nope, i’m just expecting to inherit from SiteTree