gatsby support?

[tsdexter]

Hi @jasonbahl,

You mentioned in the announcement post about Gatsby suffering due to using POST requests, but never came back to it.

Is there any documentation as to how Gatsby can benefit from this? Based on the brief mention, it seems the only way a fully static Gatsby site would benefit would be by switching to GET requests and/or using saved queries. How would this be done though? Seems to me it would require substantial changes to gatsby-plugin-wordpress?

Can you point me in the right direction?

Thanks!

[tsdexter]

bump

[jasonbahl]

@tsdexter you'll need to chat with the folks maintaining Gatsby Source WordPress. The client needs to be able to make GET requests. I know @TylerBarnes tinkered with that at some point, but I'm not sure if anything official came of it, or if there's a setting to allow you to override the default POST requests, etc.

Gatsby would almost certainly need to play nice with Persisted Queries as well, because the query strings Gatsby sends over would likely often exceed Query String limits for GET requests, which is solved by persisted queries and querying via queryIds

[jasonbahl]

tbh, Gatsby might not even benefit that much from it, because of how Gatsby talks to WPGraphQL.

Gatsby introspects the schema and fetches everything it possibly can whenever the schema changes, so new queries with different fields will all be cache misses. There's a lot of things that could change in your Schema that would cause Gatsby to generate new queries, and even if you're not using any of the data represented by the schema changes, Gatsby's still going to ask for it, sending new, different queries that would be cache misses anyway.

When using something like FaustJS + Next (what WPGraphQL.com is built on) you're querying only what you need for the templates that need it, so the queries can get more benefit more consistently from this type of caching.

[jasonbahl]

@tsdexter so it could help with re-builds, as long as the schema doesn't change in between.

Like if you change a template, and want to do a full re-build, if Gatsby were able to get cached responses from the WordPress server, it would speed things up. You've cleared your Gatsby cache (gatsby's copy of the data) but the graphql responses could still be cached in the WP Engine network cache, so Gatsby would get the data faster.

There's definitely benefit in some cases, but also a lot of cases where the benefit wouldn't be there.

[jasonbahl]

If you're using Gatsby Cloud, it's in a way trying to solve the same problem in a different way. Gatsby Cloud copies all your data from WordPress (that's a cache) and then Gatsby reads from that.

When the schema changes, Gatsby re-fetches from WordPress and re-populates Gatsby's copies of the data.

When the re-fetches are caused by a schema change, any query that included that schema change would be a cache miss against WordPress, but other queries would still be a cache hit.

For example, let's say you add a new field to the Post type. Gatsby would re-fetch ALL posts to get the new data and the schema change would mean the query being sent was new and thus cache misses in WordPress.

But, if Gatsby also tried to refetch pages, categories, tags, those might still be cached and Gatsby would get those responses immediately from the cache, saving WordPress processing for those unchanged entities.

So, there's potential benefit for some scenarios, for sure.

[tsdexter]

We're hosting on Atlas with scheduled builds. One clean per day and 2 "cached builds" (ie: doesn't wipe out gatsby cache folders).

In the cached build instance gatsby-source-wordpress only does the "fetching updates since last build" step. There probably wouldn't be much benefit here because they queries are specific to the updated posts. During the clean builds, we could potentially see some performance benefit so long as the data for that particular query hasn't changed, as if it has, the query would then be considered the "first hit" which isn't cached, correct?

Perhaps, @TylerBarnes can weigh in on whether or not they plan to support additional caching via this plug-in.

[TylerBarnes]

I tried out enabling object caching on a few sites and there was a significant improvement in build times (don't have exact numbers now). Switching to get requests and persisted queries would go a long way but from what I remember object caching sped up builds 25 to 30 percent

[TylerBarnes]

And yes the benefit would be for uncached builds but data updates are already fast. Cold builds are where there can be issues