Stale product data on PDP

[batzlerg]

I'm opening this as a question because it feels like a feature request, documentation request, and bug report all rolled into one.

Describe the issue
PDP product data (ServerProductQuery) is pulled during initial build in getStaticProps, and never revalidated. There is a manual client data refetch, but it uses ClientProductQuery, which is not 1:1.

This has led to at least two concrete issues in our team's experience:

• [bug] because the data in the statically-built page is stale, any time the updated data conflicts with the old data there can be a problematic flashing of old data before the new data displays. see the price example video below.
• [documentation request] because the ~manual revalidation linked above runs the client version of the product query, any API extensions added to the ServerProductQuery are fetched once during build and never re-executed, leading to an undocumented behavior where you need to extend both the server and client product query to refetch your data. see the example video below - the product's inventory has been restocked since the last app build, but because our call to get live productStock is only in the ServerProductQuery, it isn't updated by the client data refetch.

pdp_price_conflict.mp4

Possible Solution
I think the ideal solve would be to support a revalidate value to pass into getStaticProps inside p.tsx. This would be a low-lift way of allowing users to configure an expected "cache time" for product updates, without forcing teams to rebuild their application periodically to pick up catalog changes.

A more elegant solution is to allow users to revalidate on demand (for example, we could hook up to receive VTEX catalog changes via broadcaster), but exposing that functionality involves additional work.

Also, clarification to the existing documentation would be helpful - while the ServerProductQuery and ClientProductQuery docs call out the fallback / getStaticProps pattern, it would be great to highlight the implications of using two different, overlapping queries to fetch the product data, for how developers should build API extensions / think about the PDP render cycle.

[lucasfp13]

Hey @batzlerg, first of all thank you for this one, improvements proposals are always welcome and help us to evolve even more the product 🤝

Regarding the bug I have a question: do you think that having slightly different queries being fetched (one on server and the other on client-side) are a problem, or is the refetch itself bad?

Even though the on-demand revalidation (ISR) is still in our sights, we don't support it on our infrastructure yet, but it would be the best possible solution indeed.

[batzlerg]

Regarding the bug I have a question: do you think that having slightly different queries being fetched (one on server and the other on client-side) are a problem, or is the refetch itself bad?

I think different queries makes sense conceptually, because some data will become stale more rapidly than other data.

what caught our team off guard is the intersection of two issues:

• the ServerProductQuery is really more like a StaticNoRevalidateServerProductQuery, so anything in Server but not in Client will never be refreshed.
• because there may be many instances of the FastStore application, each with its own static query, the data captured in ServerProductQuery may be inconsistent. imagine two app instances: A fetches inventory = 0 before the product is restocked, and B fetches inventory = 1000 after the product is restocked. depending on which instance responds to a given request, the user may get an inconsistent page experience between refreshes.

so until some form of revalidation is supported, I think it would help to call out in the docs that extensions to ServerProductQuery will only ever be fetched once (/ according to the described behavior above). perhaps having a shared static cache would also help in the interim, but I could see that adding more infra complexity than just supporting revalidation.