Make GraphQL schema cacheable

[andris-sevcenko]

@brandonkelly - So this is interesting - we have a headless site paired with a static site generator, and whenever the site regenerates we are seeing the server spend almost all of its time rebuilding the schema via Gql::getSchemaDef - here is some profiling we did on New Relic to see where we were spending so much time - as you can see, a ton of time is being spent in PHP, and actually very little in MySQL:

We have our rebuild pretty well-optimized (GQL caching as well as GQL batching, on pages with multiple calls), but digging into the API GQL controller I can see that even with GQL caching, it does quite a bit of work pulling the schema definition on every request. Would it be possible for the schema to be cached once the query has been validated? Seems like there is a lot of time being spent here when it probably doesn't have to.

Originally posted by @mildlygeeky in #6639 (comment)

[andris-sevcenko]

@mildlygeeky yeah, the schema definition is required for every call, otherwise, it's impossible to validate the incoming query against it.

We've tried to cache the resulting schema, but, for now, it's impossible, as GraphQL fields are defined within Closures, to help to resolve circular dependencies. When you try to serialize anything with a Closure in it, PHP throws a hissy fit about it, so there's no way currently to cache generated schema.

For Craft 4.0, I hope to add something like https://github.com/opis/closure to help alleviate this, but that's not going to happen for 3.6.

[mildlygeeky]

Aaah - that makes sense around closures being the reason why you can't simply memoize/serialize. Thanks for the explanation, @andris-sevcenko, and hope to see this in a future release.

[mildlygeeky]

@brandonkelly @andris-sevcenko if I could put together a PR for this, might this something that could get into 3.x (3.7)? Really seeing a lot of stress on Craft for sites using heavy use of GQL, and would be happy to look at caching this (thought is it would respect Craft's overall GQL caching, and break the cache for this in the same way).

[andris-sevcenko]

@mildlygeeky, I decided to give it a shot and see what I can come up with.

So, the problem here was that the Schema on the PHP end is a complex beast. It's not only a GraphQL schema to validate a query against, but it also holds all the knowledge on how to resolve different fields and whatnot. Further, since entries can relate entries, for example, the fields have to be defined as callbacks, otherwise, you end up with infinite loops. Now, to go to an even more fun place, callbacks/closures cannot be serialized, so it's hard to cache without any wizardry.

Thankfully, there are excellent libraries out there that can do this for us, and we should assume that it's with decent performance. Maybe not perfect, but probably not too much overhead on top of PHPs serialization goes into wrapping all the closures in classes so they can be serialized.

Long story short, I made that happen.

Now, let's take a detour. If you're not in the mood for detours and rambles, skip to the end.

I don't recall if you were a fan of Game Of Thrones, but we can probably all agree that George RR Martin is a master of plot twists and great stories in general. Did you know he started by writing science fiction stories?

I was not aware of this until I went hunting for the science fiction story I recalled that pairs up nicely with this GH issue - it was a story I read a long time ago as part of this book. The story, it turns out, was by George RR Martin, and it was called FTA. If you're not into science fiction, you can read the plot synopsis here. If you are, well, that book has some good stories.

Anyway, as you might have guessed, caching is way slower than generating the Schema every time. About 3x slower.

I'll look into some more, uhh, "experimental" solutions that might be available on some hosts.

[andris-sevcenko]

In particular, maybe preloading can be made to work here, but that requires PHP 7.4, so the Craft 4.0 milestone still remains.

[andris-sevcenko]

Brainstormed a little bit with @Wiejeben over Discord about this.

Currently, seems like the best (maybe the only) realistic approach here is to leverage Swoole here as a dedicated GraphQL server which holds the Schemas in the memory.

Then, using the Gql::EVENT_BEFORE_EXECUTE_GQL_QUERY a plugin could just forward the request to the Swoole server, which would execute the query then and return the results. Obviosuly, this is a rough draft of how that might work, but it's something.

[mildlygeeky]

Long story short, I made that happen.

Now, let's take a detour. If you're not in the mood for detours and rambles, skip to the end.

I don't recall if you were a fan of Game Of Thrones, but we can probably all agree that George RR Martin is a master of plot twists and great stories in general. Did you know he started by writing science fiction stories?

I was not aware of this until I went hunting for the science fiction story I recalled that pairs up nicely with this GH issue - it was a story I read a long time ago as part of this book. The story, it turns out, was by George RR Martin, and it was called FTA. If you're not into science fiction, you can read the plot synopsis here. If you are, well, that book has some good stories.

Anyway, as you might have guessed, caching is way slower than generating the Schema every time. About 3x slower.

I'll look into some more, uhh, "experimental" solutions that might be available on some hosts.

Friends, this is why I will forever "stan" for @andris-sevcenko. You crack me up, man.

[mildlygeeky]

One way to support this without fully building Swoole support into core may be to include a gql.php script in web, and mount that as an endpoint for the craftcms/docker containers with Swoole's official docker image (https://github.com/swoole/docker-swoole/tree/master/examples/03-nginx) - we're going to try this out for a new build, and will report back on how it goes.

[andris-sevcenko]

I can confirm that there are quite a few issues with Swoole to make it stable and reliable. For what it's worth, I was able to accomplish this with minor changes to Craft itself.

There are still quite a few things to take care of to make it even alpha-worthy, but it might happen for Craft 4 with a plugin in compatible environments.

Screen.Recording.2021-09-24.at.12.48.31.mov

:

[mildlygeeky]

Oh, now you're just teasing me @andris-sevcenko

[andris-sevcenko]

Error handling is non-existent and when Swoole goes down, it goes down hard. It's not ready for commitment yet, @mildlygeeky :)

[Wiejeben]

I feel like this would best be implemented as some kind of daemon which you can configure Craft to forward GQL queries to, whenever the daemon is down it could fallback to the current way of handling GQL queries. This would also add a layer of security to not expose the Swoole server on whatever alternative port (plus how to deal with HTTPS and all that).

[andris-sevcenko]

@Wiejeben Swoole can run as a daemon, too. Also, in this case, it's configured to listen to the 127.0.0.1 network address, so is already inaccessible from outside.

Or am I misunderstanding you, @Wiejeben?

[FreekVR]

Not sure if this helps, but lighthouse-php, the Laravel package for building GraphQL schemas, does have caching. They seem to have solved this by writing the compiled schema to the filesystem as a PHP file;

https://lighthouse-php.com/5/performance/schema-caching.html
https://github.com/nuwave/lighthouse/blob/16de64b257589b3901c4aedb15920625c605caee/src/Schema/AST/ASTBuilder.php#L97

Might this be a route that could be taken for Craft, too?

[brandonkelly]

Ohh interesting. Thanks for pointing that out @FreekVR

[andris-sevcenko]

That is not that different, in the end. There's quite a bit of overhead to make the AST cacheable and you still end up with serializing and unserializing a bunch of stuff. Also, there's additional overhead to detaching and re-attaching all the lambda functions (resolvers and field definitions at the very least).

For what it's worth, it's not an answer I've come up with out of the blue - "it's more efficient to efficiently lazy-load than cache" is a sentiment that's also shared by @markhuot (author of the original CraftQL plugin) and @vladar (author/contributor of webonyx/graphql-php)

[Wiejeben]

Unless this is now something on the roadmap of Craft, I feel like this question has actually gone unanswered.

[mildlygeeky]

Agreed - GraphQL performance is real tough on a large schema as-is. Right now we’re using Stellate (formerly GraphCDN) to get around it, but would really like to see faster GQL out of the origin endpoint, especially for everything we can’t cache.

[tekstrand]

We're seeing this issue as well under peak loads, is this still being considered for improvement?

[brandonkelly]

Still on our radar, but the initial ideas we’ve explored haven’t really moved the needle.

[dwgebler]

@andris-sevcenko did you ever manage to get anything working for caching the schema definition via opis/closure? I've been trying to do this as a workaround and although I can produce a serialized representation of the schemadef, when I try to unserialize it I get an error ("error at offset..." PHP error which indicates a corrupted serialized string)