-
Notifications
You must be signed in to change notification settings - Fork 201
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple critical performance improvments. #1314
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I understand that these changes make things faster, there's also a few things that cause these changes not to be mergeable as-is and I think larger changes are required.
We don't know when a schema comes from the cache and when it's loaded from disk for the first time. The current change disables validation in all cases, but it's important that the schema is at least validated at some point.
Your change always removes location data, but there are cases when location data might be very useful, for example when developing the schema. Additionally there may be production cases (like profiling) which might want location data too. So always disabling it is not an option. We'll have to identify when it's appropriate to disable, or create the right configuration for end users.
I'm not entirely sure what your change for the schema extension is trying to do, but it appears as if we're rebuilding the schema entirely, rather than only building the extension on top of an existing schema? This feels like it might also need a rethink (or a better explanation of what's happening).
EDIT: Ah the original issue has more explanation of what's going on :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I will try to rewrite this a bit in a separate PR
@@ -119,13 +120,14 @@ public function getSchema(ResolverRegistryInterface $registry) { | |||
$extensions = $this->getExtensions(); | |||
$resolver = [$registry, 'resolveType']; | |||
$document = $this->getSchemaDocument($extensions); | |||
$options = ['assumeValid' => TRUE]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should only do this in prod, so we should check empty($this->inDevelopment)
* @throws \GraphQL\Error\Error | ||
* @throws \GraphQL\Error\SyntaxError | ||
*/ | ||
public function getExtensionSchemaAst($schema, $extendSchema) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is confusing now, we already cache an AST in getExtensionDocument()
. here we cache something again, why?
} | ||
|
||
$schema = SchemaExtender::extend($schema, $extendSchema); | ||
$schema_string = SchemaPrinter::doPrint($schema); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is clever, I like the idea! We construct a final AST with all extensions and then cache that 👍
This was done, closing. |
Multiple performance improvements:
noLocation
to avoid recursions