Bot releases are visible (Hide)
Published by jasonbahl almost 3 years ago
Full Changelog: https://github.com/wp-graphql/wp-graphql/compare/v1.6.6...v1.6.7
Published by jasonbahl about 3 years ago
Full Changelog: https://github.com/wp-graphql/wp-graphql/compare/v1.6.5...v1.6.6
Published by jasonbahl about 3 years ago
Published by jasonbahl about 3 years ago
asQuery
argument could return an error instead of a null when the ID passed could not be previewed.Published by jasonbahl about 3 years ago
Header
/ header()
) would try and call the function when loading the Type. See (Issue #2047)Published by jasonbahl about 3 years ago
If you have a codebase that extends WPGraphQL the tips below will help you upgrade.
Because v1.6.0 now fully supports Lazy Loading of the Schema, you might need to update your tests to Clear the Schema during the setUp()
and tearDown()
of your tests.
Lazy loading will load only the Types of the schema that are asked for, and if you have multiple queries in your tests, the 2nd test will attempt to run with the already generated Schema which might not include all the Types you need for the 2nd test.
By using \WPGraphQL::clear_schema()
in your setUp()
and tearDown()
it resets the Schema so that each test can lazily load the Schema that it needs to fulfill the individual request.
You can see this update in the WPEngine Atlas Content Modeler plugin: https://github.com/wpengine/atlas-content-modeler/pull/212/files
Any Type that is in the Schema but only referenced within a Union or Interface should be updated to include eagerlyLoadType => true
in the Type registration.
In the WPGraphQL core codebase, there are 2 Types that are never directly referenced, just referenced as part of Interfaces:
You can see these 2 types were set to be eagerly loaded like so:
This ensures that the GraphQL Schema can load these Types even though they aren't asked for directly.
This Release has a focus on performance improvements.
GraphQL-PHP, the GraphQL library used under the hood, supports "Lazy Loading" of GraphQL Types, which allow Types to be registered as callbacks, and the full Type definitions are loaded only when needed.
For example, the following query:
{
posts {
nodes {
id
title
}
}
}
Should only load the following Type Definitions:
However, WPGraphQL wasn't using this feature of GraphQL-PHP quite right and was instead loading ALL GraphQL Type definitions on every GraphQL request.
This caused a lot of unnecessary overhead.
The improvements in this release show significant reduction in response time.
Below are some details on how things have improved. Results may vary based on your specific server setup, your schema, the queries you run, etc, but in general every user of WPGraphQL should see performance improvements after this release.
Request Type | WP Homepage | REST Endpoint | GraphQL Endpoint | REST Singe Post | GraphQL Single Post | GraphiQL Introspection |
---|---|---|---|---|---|---|
WPGraphQL 1.3.5 | 70 ms | 77 ms | 150 ms | 73 ms | 160 ms | 2585 ms |
v1.6.0 | 77 ms | 72 ms | 93 ms | 73 ms | 105 ms | 658 ms |
WPGraphQL 1.3.5 + 15 CPTs and Taxonomies | 87 ms | 78 ms | 292 ms | 79 ms | 284 ms | 6295 ms |
v1.6.0 + 15 CPTs and Taxonomies | 89 ms | 77 ms | 150 ms | 79 ms | 157 ms | 1322 ms |
To help visualize this data even more, I created some before/after charts:
Prior to the PR we can see that GraphQL requests were near and above 150ms and after we can see it closer to 100ms!
Prior to the PR, the GraphQL requests were near the 300ms and now they're cut down closer to 150ms!
And, all together we can see the different types of requests for v1.3.5 and v1.6.0:
Introspection Queries (used for tools such as GraphiQL and Gatsby Source WordPress) is also MUCH faster now.
This is how long GraphiQL in the WP Admin takes to load the schema
With 15 Custom Post Types and Taxonomies registered it was taking WPGraphQL 6+ seconds to return the Schema.
Now, it's taking about 1 second!
v1.3.5
~6 seconds before GraphiQL has the Schema and is ready to use
v1.6.0
~1 second and GraphiQL is ready for interaction
The WPGraphQL Model Layer does a series of checks on each node to make sure that the requesting user has permission to see the nodes requested.
When a list of posts is queried in GraphQL, the Author(s) of the posts must also be loaded behind the scenes to properly determine whether each post in the list can be returned to the requesting user.
Let's say a list of draft posts were queried. If the request were public, no results would be returned. But, if the request were authenticated, then we'd need to know who the requesting user is, what capabilities they have, and whether they're the owner of the post(s) being returned.
If the requesting user is the Author of the post, they can see it. If they're not the author, then we need to check their capabilities. If they don't have proper capabilities to read others posts, they shouldn't see the post.
Long story short, querying a list of posts requires more than just returning raw data from the database, it requires added context of the requesting user, of the application layer (roles and capabilities of each post_type, etc) and ownership of each node being returned.
In the past, one check WPGraphQL performed to ensure User nodes were public, was to run the count_user_posts()
function for each author loaded for the request.
This was expensive and required many SQL queries to fulfill.
In fact, for a "simple" query such as:
{
posts( first: 100 ) {
nodes {
id
title
content
}
}
}
This would generate 113 MySQL queries to fulfil:
But with the changes here, we're down to 13 queries, reducing the total queries by 99 for this request, and cutting the total SQL query time nearly in half!
Results will vary from site-to-site based on data sets, etc, but this is a significant improvement and should improve performance for most users of WPGraphQL.
Published by jasonbahl about 3 years ago
Published by jasonbahl about 3 years ago
after_execute_actions
weren't properly set for Batch Queries.graphql_before_execute
and graphql_after_execute
to allow actions to run before/after the execution of entire Batch requests vs. the hooks that currently run within each the execution of each operation within a request.Published by jasonbahl about 3 years ago
Published by jasonbahl over 3 years ago
Published by jasonbahl over 3 years ago
Published by jasonbahl over 3 years ago
Published by jasonbahl over 3 years ago
Published by jasonbahl over 3 years ago
MenuItem.path
field from nonNull
to nullable as the value can be null in WordPress. Thanks @furedal!Published by jasonbahl over 3 years ago
No functional changes. See release notes for v1.4.2.
This release simply fixes a mistake with v1.4.2 release/deploy process where changes were not properly deployed.
Published by jasonbahl over 3 years ago
uri
field on Terms was returning null
. The issue was actually wider than that as resolvers on Object Types that implement interfaces weren't being fully respected.SpaceAfterFunction
Code Sniffer rule and adjusts the codebase to respect the rule. Thanks @markkelnar!