You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Run-time calls to the GraphQL API to fetch data introduce latency and delay to the application.
Investigate whether we can fetch any data that the initial load of the application needs at build time and preload the application with it.
Risks / Caveats
We don't know the frequency of builds. It may be entirely possible that the site is only ever "built" once.
We don't know the frequency of data updates. How will the application "update" this data if it is changed in the M2 Admin (for example) after build time?
It may be entirely possible that the result of this investigation is "we should not do this".
We already do this in the webpack configurator. Unclear whether that should continue to happen now that we support multi-store and also we need to be able to react to config changes without forcing a client to rebuild their runtime bundle.
The storeConfig query provides a lot of information but it is store specific. Perhaps a better thing to do would be to understand the specific data we want to pre-fetch, do it for all possible stores, and make that call happen in the service worker. I'm closing this for now, to clean up our github issue log, but if you think it is worth an investigation we should open an internal JIRA ticket :)
Overview
Run-time calls to the GraphQL API to fetch data introduce latency and delay to the application.
Investigate whether we can fetch any data that the initial load of the application needs at build time and preload the application with it.
Risks / Caveats
It may be entirely possible that the result of this investigation is "we should not do this".
References
The GraphQL project documentation has good information on what data changes and how frequently (and when it should be updated).
The text was updated successfully, but these errors were encountered: