Next.js Discord

Discord Forum

Ecommerce websites: getStaticProps or getServerSideProps?

Unanswered
Polar bear posted this in #help-forum
Open in Discord
Polar bearOP
What's the most common approach when it comes to bulding ecommerce websites with NextJS? What I mean is, let's say you have 1000 products, do you use getStaticPaths+getStaticProps or do you use getServerSideProps? What's the most common business requirement for ecommerce websites in this regard? Do they tell you that the products have to be always updated (so, getServerSideProps) or do they tell you that they only make changes every once in a while (getStaticProps)?

14 Replies

Upland Sandpiper
is it still used in Next JS 13 latest ?
joulev
yes if you use the pages router
@Polar bear What's the most common approach when it comes to bulding ecommerce websites with NextJS? What I mean is, let's say you have 1000 products, do you use getStaticPaths+getStaticProps or do you use getServerSideProps? What's the most common business requirement for ecommerce websites in this regard? Do they tell you that the products have to be always updated (so, getServerSideProps) or do they tell you that they only make changes every once in a while (getStaticProps)?
joulev
i cant say on the most common approach because i havent worked on every ecommerce website on earth, but i normally make the decision based on how often the data changes

if there are not many products and they are not updated too often, getStaticProps + on-demand revalidation is probably the best way

but when there are a lot of products, on-demand revalidation doesn't offer much benefit anymore, then i prefer getServerSideProps for simplicity in syntax
@joulev i cant say on the most common approach because i havent worked on every ecommerce website on earth, but i normally make the decision based on how often the data changes if there are not many products and they are not updated too often, `getStaticProps` + on-demand revalidation is probably the best way but when there are a lot of products, on-demand revalidation doesn't offer much benefit anymore, then i prefer `getServerSideProps` for simplicity in syntax
Polar bearOP
in the ecommerce projects you've worked on, how frequently did the client/customer updated the products? When you mention on demand revalidation, do you mean using the revalidation prop? One thing I noticed (I dont know if I'm doing it wrong) is that if i set the revalidate to 5 minutes and then I change a product using my CMS (Strapi), I have to wait 5 minutes to see the change in the frontend - Should I add some kind of webhook inside Strapi that sends a petition to the NextJS website to force it to revalidate the data? Or am I required to set the revalidate prop to a low value like 30 seconds or less?
@joulev > When you mention on demand revalidation, do you mean using the revalidation prop? no. I used this <https://nextjs.org/docs/pages/building-your-application/rendering/incremental-static-regeneration#on-demand-revalidation> and no `revalidation` props
Polar bearOP
Awesome, I see that you can revalidate a specific page which is very handy, just to clarify the flow: my CMS would send a post request to a NextJS api endpoint which would trigger revalidation for a specific page, right? I mean, if I have 1000 products and then change the description of one of the "levi-jeans" product, this petition would run inside NextJS: res.revalidate('/products/levi-jeans') revalidating only that specific page data, no?

So I wonder: if only one part of the product page changes frequently (for example a counter that shows you how many times the product has been bought, purchaseCounter), would it be a good idea to still use getStaticProps for everything in order to reduce strain on the server, and run a fetch call client-side to get the value of purchaseCounter and only render that part client-side? Does this have any downsides? I'm thinking I could use fallback:true so that when google crawl bots visit the website, they get a fallback:blocking version so they don't see any loading spinners or a text like "Loading purchase counter"
@joulev I would use client side fetching too, but the downside is that it is not SEO friendly (unless you also prefetch that on the server) hence google will see that loading state and won’t know the counter value
Polar bearOP
Oh, so using fallback: true / fallback: blocking wouldn't work to prevent the bot from seeing the loading state, right? On the other hand, how would you prefetch that counter value in the server and how would you pass it to the page that uses getStaticPaths/getStaticProps?
@Polar bear Oh, so using fallback: true / fallback: blocking wouldn't work to prevent the bot from seeing the loading state, right? On the other hand, how would you prefetch that counter value in the server and how would you pass it to the page that uses getStaticPaths/getStaticProps?
joulev
export async function getServerSideProps() {
  const count = await getCount();
  return { props: { count } };
}

export default function Page({ count }) {
  const { data, isLoading } = useDataFetchingHook("/api/get-count", { initialValue: count });
  if (!isLoading) return null; // doesn't happen
  return <div>{data}</div>;
}
i think react-query also has built-in API for server-side prefetching and client-side hydration
@Polar bear Thank you, that getServerSideProps count data you would pass it with useContext to the product page that uses getStaticPath/getStaticProps right?
joulev
uhmm no, this getServerSideProps data is only available to the page having this getServerSideprops
Polar bearOP
hmm but I would only use getStaticProps for the products slug page, so then the only way to pre-fetch the count value that gets rendered client-side would be using react-query right? I mean, in order to lessen the SEO penalty since the count is the only thing in the page that gets updated frequently and rendered client-side