Query on demand in gatsby develop
#27620
Replies: 7 comments 17 replies
-
|
I've tested this feature for local development of https://coggscircus.com/ and toggling the flag from false to true reduced "server boot finished" time from As you mention in your original post, I encountered a few issues with enabling the feature: both However, these are some pretty significant improvements so it definitely seems worth working out these bugs. Awesome work! 😀 |
Beta Was this translation helpful? Give feedback.
-
|
Hey Sophia! Awesome -- thank you so much. We will try and address those issues you identified. Would you be willing to jump on a call to discuss them? If so -> https://calendly.com/dschau/user-research |
Beta Was this translation helpful? Give feedback.
-
|
Sure thing! I've booked a time. |
Beta Was this translation helpful? Give feedback.
-
|
@sandren that's an incredible site! 😍 😆 |
Beta Was this translation helpful? Give feedback.
-
|
Hi Sophia, I just wanted to mention that the latest stable version of We did quite of few fixes and hopefully improvements since the canary version was released, so the problem with first run might have been addressed. I don't think I saw this particular problem when trying it on various sites, but we saw other problems that might have same root cause. If it's not fixed, I suspect there might have been some specific trigger in your site setup that triggered it (to be clear - it's not that setup is wrong, but it might be something specific or combination of things that we didn't test against). If the issue would persist - I do hope to try to debug it, ideally on your site :) We didn't add loading indicator yet, but I do agree that this is jarring (specifically for the heavier queries, queries that trigger some image transformations, etc) and it is added to list of known issues (listed above and dedicated ticket to keep track of it is in #28182 ). I also added few more known issues on top of what we already knew a month ago that we discovered when doing much more testing. Those do need to be fixed, but we thought that for experimental opt-in feature the trade-off of shipping what was already working sooner and making sure we have a list of problems was worth it (specifically if those issues are not impacting every user) Lastly - I do want to thank you so much for taking the time to test it out and provide feedback - this is really invaluable information! |
Beta Was this translation helpful? Give feedback.
-
Latest release (
|
Beta Was this translation helpful? Give feedback.
-
|
I have a noob question. Where do I put the flag? gatsby-config.js? |
Beta Was this translation helpful? Give feedback.
-
|
Hey @abdullahe! You can add it in process.env.GATSBY_EXPERIMENTAL_QUERY_ON_DEMAND = "true"
// regular gatsby config
module.exports = {
siteMetadata: {
title: `Gatsby Default Starter`,
description: `Kick off your next, great Gatsby project with this default starter. This barebones starter ships with the main Gatsby configuration files you might need.`,
author: `@gatsbyjs`,
},
plugins: [
// your plugins
]
}Order doesn't matter - so if you have |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
This is a great feature, thanks! For us the initial build time has gone down from around 80s to 40s which is a pretty good improvement. We'd already done optimisations like using Interestingly, for us the bottleneck in initial load times is actually loading the data, as well as querying it. We're generating around 12,500 pages parsed from around 400 large JSON files, loaded from an external API. Each of these API requests takes around half a second so that's around 3 and a half minutes loading data. Alright, we run them async in parallel batches so it's not quite that long, and we have a minimal fake version of the API for local dev but you get the idea. So, another related feature that could speed things up is sourcing on demand or lazy sourcing as well as query on demand. So for example, having a Anyway, I realise that's gone a bit off-topic and apologies if that's something that's already in discussion elsewhere but I thought I'd mention it! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the feedback! We are absolutely aware that sourcing data will be one of next bottlenecks to cover, but this one will be tougher as it might require our API changes and therefore require entire ecosystem to migrate and because of that the API design for it will need a lot more exploration. #28214 is not really related to lazy sourcing - just example that we are thinking about sourcing bottlenecks too! https://gatsby.dev/lazy-devjs-umbrella is another example of similar approach as done here for queries - this time for webpack compilation - specifically in more complex sites with huge number of distinct page templates, the speedup for webpack step can also be quite noticeable. And lazy image processing is yet another (this one is less fleshed out for now, but it does work!) |
Beta Was this translation helpful? Give feedback.
-
|
When enabling query-on-demand on gatsbyjs.com I get the following issue: Lazy images is on as well |
Beta Was this translation helpful? Give feedback.
-
|
I did try couple times and couldn't reproduce this - I don't think this is related to query on demand actually and rather was problem of flaky |
Beta Was this translation helpful? Give feedback.
-
|
Same - I've seen with and without QoD today |
Beta Was this translation helpful? Give feedback.
-
|
@pieh |
Beta Was this translation helpful? Give feedback.
-
|
In my case, it seems to be causing multiple reloads because I have template pages that get generated with queries, and losing eager construction of these template pages seems to cause them to build when links to the pages are hovered/about to be accessed. Any information regarding disabling the feature, or plans for resolving the incompatibility with query generated pages would be appreciated. |
Beta Was this translation helpful? Give feedback.
-
|
This was published as GA. See https://www.gatsbyjs.com/docs/reference/release-notes/v2.30/#query-on-demand-and-lazy-images-generally-available This is not an optional feature starting with @nikoladev @FileManagerKim Please open a new issue (preferably with reproduction) so that we could help you fix the underlying problems. P.S. 1 minute for a query is too slow - queries must be much faster. We should investigate and fix the actual underlying problem that makes your queries that slow. |
Beta Was this translation helpful? Give feedback.
-
|
I unfortunately cannot show a reproduction due to time and confidentiality constraints. Is there a possible way to revert to a previous build of gatsby for an existing project? |
Beta Was this translation helpful? Give feedback.
-
It could very well be that my queries aren't written (or used) in an optimal fashion and that it only now surfaced because of query on demand. I also had multiple tabs open pointing to the same page (testing out different breakpoints) so it could be that that made it worse. After it finally loaded it was quick again afterwards.
I don't have time for that right now, but if it keeps being slow I'll make some time and create an issue. Though I will take some notes right now on what I changed before it became slow, because I've been on |
Beta Was this translation helpful? Give feedback.
-
|
@FileManagerKim The only way to disable it is to roll back to @nikoladev Make sure you're using the latest |
Beta Was this translation helpful? Give feedback.
-
|
Hi,
I have the code above within my package.json to yarn start to run my gatsby project, but then I ran into the error of
How would I go about to solve this problem? I am on Windows 8.1. My coworkers are all on mac, and they seem to not have this problem. Thank you |
Beta Was this translation helpful? Give feedback.
-
|
If you are on windows you need to install and change your script to: But also latest versions of Gatsby include query on demand by default and you don't need to use those flags to enable it. |
Beta Was this translation helpful? Give feedback.
-
|
In version 2.30 we released this as generally available (GA): https://www.gatsbyjs.com/docs/reference/release-notes/v2.30#query-on-demand-and-lazy-images-generally-available Hence I'll lock this discussion here as the beta is over. Thanks everyone for testing! |
Beta Was this translation helpful? Give feedback.
-
This feature was released in 2.30: https://www.gatsbyjs.com/docs/reference/release-notes/v2.30#query-on-demand-and-lazy-images-generally-available
Gatsby currently eagerly runs all the queries in development mode. This results in longer and longer boot times for the development server as the amount of content/pages increases.
In
gatsby@2.27.0we introduced experimental Query on demand feature that doesn't eagerly run all the page queries in development mode. Instead of running those eagerly, we will run them when the user actually navigates to a page in a browser (but only if we didn't run the query yet, or if the result is not up to date - for example after changing content used to generate query results). We continued working on it and were releasing incremental improvements with each release.In
gatsby@2.29.0we started partial rollout and enabled this feature for randomly selected portion of repositories. If your repository was selected and you want to opt out of this behaviour you can addflags: { QUERY_ON_DEMAND: false }to yourgatsby-config.js. If you do that please let us know in comment what caused decission to not use it - we want to address those issues! If your repository wasn't selected - read on - you can manually enable it.How to test & help out
Make sure you are using at least
2.29.0version ofgatsby. Try out the feature on your site by addingflags: { QUERY_ON_DEMAND: true }to yourgatsby-config.js(here's example - pieh/gatsby-starter-blog@ef0aced) and rungatsby developReport any errors or other problems you might see. Please also check "Known Deficiencies" below to check for known issues, limitations and additional future work planned for this feature.
We'd love also for you to report if you see improvements on your site and if you do then how much faster it is!
What can you expect?
If
run page queriesstep is taking a long time when you initially rungatsby develop(or later on when server is already up and you edit your content and/or queries), you can expect this step to drop significantly. We still do run queries for some pages eagerly, but those are just 404 pages and index page for initial start.Be aware that depending on how heavy your page queries are - you might see some increased loading time for pages that don't have up-to-date query results. This leads to another point - we don't run queries unconditionally on each page load! Gatsby does keep track of when queries actually need to rerun. They will rerun when data used for page actually changed or when you edit page query. This means that after we do run query for a page we will reuse those cached results for as long as we can.
Loading indicator
We did add loading indicator (in
gatsby developonly! It will not show up in production builds.) for cases when running query take longer than a second. Here's little demo of it:We do automatically disable showing this indicatator when running in
cypressenvironment ( to make sure this UI element doesn't interfere with your end-to-end tests workflows).We also allow to disable it for current
gatsby developsession by visitinghttp://localhost:8000/___loading-indicator/disableendpoint in case it interfere in other scenarios (note you can also re-enable it later by usinghttp://localhost:8000/___loading-indicator/enable). We also added friendly debug log in browser console after first time it is shown (we did set message todebuglevel so you might need to adjust log filtering in your browser - we don't want to spam your browser console):Image processing
If you do use
gatsby-plugin-sharp(either throughgatsby-transformer-sharp,gatsby-remark-imagesand/or plenty of other wayssharpimage processing is triggered) this is often one of most heavy work that happens. Using Query on Demand helps in sense that we can skip even starting the work on all the image processing by just not running all page queries that would trigger said processing. But we still need to do this work for pages that you will visit. But we have good news here! Check out Lazy Image Processing ingatsby developthat applies similar mechanism for image processing. While implementation wise Lazy Image Processing is "separate" project, using it together with Query on Demand is what we recommend - Query on Demand will prepare the data for page when you navigate to it and Lazy Image Processing will trigger image processing when browser actually need to display those images (so when they are in viewport or "close to" viewport).Known Deficiencies
Running in CI environment
Currently we disable query on demand in CIs. Reason for this is that running
gatsby developin CIs has some characteristics that are different from local development - primarily related to logging. Query runs can throw errors, those errors are much more visible when running locally because terminal runninggatsby developis usually open somewhere on develop's machine and it's quite natural to check it if something doesn't update when it should. In CIs logs are also available, but it often requires users (runninggatsby developis more often used by content editors than developers) to check CI specific logs viewers. Delaying those logs to when user navigate the site makes it quite weird experience. We possibly could drop this "gotcha" if we would forward those warnings to browser, but we don't do it right now.Passing data via page context:
If you query for content in
gatsby-node.jsand pass that data via page context (either completely skipping page queries or using mix of page context and page queries), then this feature might have no (or limited) impact. In particular:gatsby-nodeis not something that this feature can skip, because they are not part of page query running (querying them in page queries and NOT in
gatsby-node.jsis where this features shines actually!).If you are passing your data via page context - consider trying out migrating to using page queries. Historically this was done to workaround performance issues when dealing with large amount of data (page queries were slower than doing single huge query in
gatsby-nodeand chunking data programmatically), but there was lot of improvements there since this workaround started seeing a lot of use. Just to illustrate - see #20729 change in particular and broader list that expanded perf improvements making the use of this workaround not needed anymore.Mdx
gatsby-plugin-mdxcurrently needs to do a lot of processing already at data sourcing time. There still should be visible improvement when mdx is used via page queries with this feature (running page queries still benefits from it, just overall it's not as drastic due to other bottlenecks)Static queries and 404 page queries
First, let me make sure this is communicated - those do work, they are just not "on demand". This means we still eagerly will pre-run all static queries as well as 404 and Gatsby's development 404 page ( https://www.gatsbyjs.com/docs/add-404-page/ ). Reason for this is that making all kind of queries work on demand requires more refactors and changes than what we managed to do so far (but it's doable!). Think of it as progressive shipping of the feature that provide more and more value in each step without waiting to cover all possible improvements and make one huge splash (at much later date).
Data fetch request can occasionally stall for longer than time it takes to generate query results
The data requests can sometimes stall and actually take much longer than query result generation itself. This seems to happen when query running takes longer than 5 seconds (could be heavy query - for example including lots of image processing, could be result of some concurrent work like webpack recompilation, etc). See #28184
Running queries on demand trigger query extraction each time
On some sites query extraction step adds noticable delay between requesting data and receiving it. We are working on skipping this step when possible ( see #28595 )
Updates history
15 Dec 2020
Loading indicator released in stable
2.29.0. Partial rollout (mode is being enabled for randomly selected portion of repositories) started.11 Dec 2020
Added loading indicator ( #28562 ). Loading indicator will be included in
gatsby@2.29stable release, it is available ingatsby@nexttag now04 Dec 2020
Added ability to turn feature on via
gatsby-config.js19 Nov 2020
After a lot of fixes, more testing and various optimisations, Query on Demand ships to stable release (
2.27.0) behind opt-inGATSBY_EXPERIMENTAL_QUERY_ON_DEMANDfeature flag. It has few known issues (that are documented above) that will be addressed in future minor and patch releases. We feel it's good enough to invite more people to try it out and share their feedback about it (including bug reports!)23 October 2020
Initial
gatsby@qodcanary version released. It had quite few issues as reported in #27620 (comment)Beta Was this translation helpful? Give feedback.
All reactions