Apologies for the double comment but another flaw I’ve seen with Gatsby in eCommerce has to do with fetching the product listings...

You basically have two options: (a) fetch them dynamically (b) trigger a rebuild on product update

With (a) you have spinners and potentially worse SEO. With (b) you have to deal with a delay from hitting “Publish” to seeing the changes deployed in prod...

Again, these are all solved problems in just about every other eCommerce framework!

If you look at some of the Gatsby eCommerce prod examples you will see a few gorgeous sites (the Flamingo one for example) but they all have very few product references and features (no user accounts, etc)

All this is to say the possible use cases for Gatsby in eCommerce seem very narrow, though I would love to be proven wrong.

I don't see a good fit between and ecommerce site and gatsby, on an ecoomerce site you may have to change your pages depending on the stock, and disable the buy button when there's no stock for an item. What are you going to do? redeploy the site on every purchase?

Or you can only list the product and make the buy button and items available come from an api, doable, but then you start to loose the simplicity of gatsby.

Yea, essentially what I'm saying in my a vs b scenario.

> Or you can only list the product and make the buy button and items available come from an api, doable, but then you start to loose the simplicity of gatsby.

And you still haven't solved the issue of delays between content changes and deployment... What if someone has made a bad mistake in content editing and you need to revert it? You're exposed to the whims of your build processes and infrastructure... There's no way I can sell to anyone who's played with Wordpress or Shopify "well, your changes might take anywhere from 3 to 15 minutes to be live..."

That's why I'm asking, how can product and engineering teams justify this kind of thing? I'm not being facetious, I'd love to hear their perspective.