top | item 25204789

Next.js Commerce store, one-click deploy to Netlify

141 points| Pebbleboi | 5 years ago |github.com | reply

66 comments

order
[+] fractionalhare|5 years ago|reply
Heads up: it looks like the company behind this (Chec) collects and stores a significant amount of data from the usage of the Commerce.js SDK featured here; including customer name, email address, phone number, IP address, device fingerprint and transactions. The privacy policy isn't particularly clear about how this is used, but it's very permissive and vague. It also states that this collection is "mandatory." In my experience this means it will be repackaged as "analytics" and sold for market research and advertising.

Be wary when using eCommerce SDKs, especially in the absence of exact, legalese-free clarification about what "data processing" means. Here is the privacy policy: https://www.iubenda.com/privacy-policy/60591797/full-legal

Keep in mind that if Chec is acquired, the durably stored data will also be transferred per this policy. Beyond the usual callouts like fraud and geolocation, the policy also allows the company to use customer data to "improve its services", with no specificity on what exactly that would entail.

[+] deepstack|5 years ago|reply
By default stripe.js (one version ago), the default button they included on their getting start page does the same thing, it took us a really long time to implement the custom api that will only submit the credit card number info + amount charged + zip to strip and rest of stuff (customer name, email address, phone number and transactions, etc) to our server.

What bothers me about these lowering the bar for new front end developer/designer is that it is free feast for these kind of non compliance :(

[+] piaste|5 years ago|reply
Yeah, this is extremely in violation of the GDPR.
[+] ZephyrBlu|5 years ago|reply
8.2 MB initial page load and slow as hell (1-2sec) when trying to navigate between pages. It was so slow I thought the site wasn't doing anything.

It looks like rendering a new page is blocked until API requests to both "categories" and "products" endpoints are completed, which is terrible. They should be background requests that aren't render-blocking. Also, these requests fire _every time_ you click a link.

Right now, the user experience is 0/10. Would not recommend.

[+] thawab|5 years ago|reply
One of the reasons is that the page is not using next.js 10, which has image optimization built in, for comparison you can check the ecommerce app built in next.js 10 here:

https://demo.vercel.store/

[+] akmittal|5 years ago|reply
Culprit is large image than necessary as its always the case. Out of 8.4 MB transfered 7.5 are just images. Product images which they are showing in 400x500 viewport has actual size of 2400x3600 (7x). I think NextJS introduces <Image /> component im not sure how much that would have been useful.
[+] dawnerd|5 years ago|reply
Definitely not the images causing it to be slow as suggested in the replies. It's just poorly built. I have a next app that was using the older version with massive images and navigation was near instant.
[+] stevenkkim|5 years ago|reply
To be fair, the bulk of the page load consists of large unoptimized images. My page load was 9.1 MB of which 8.1 MB were images and 446 kB was react devtools. So that means the rest of the site is about 0.5 MB.
[+] adevx|5 years ago|reply
"It looks like rendering a new page is blocked until API requests to both "categories" and "products" endpoints are completed" This could be the known issue[0] with how Next.js does Server Side Rendering with getServerSideProps(). It calls this on every page transition, even client side. Often resulting in unnecessary loading of initial data.

[0][https://github.com/vercel/next.js/issues/11897]

[+] IshKebab|5 years ago|reply
It's not just that the page loads are slow - they give you zero feedback that something is actually happening. Chrome's progress bar never appears, links don't change style, etc.
[+] okbel|5 years ago|reply
The title looks pretty misleading IMO. Next.js Commerce can be found here (https://nextjs.org/commerce) and it's not related at all to this repo shared here.

Some notes:

- This looks like a SPA - And it's a really bad pattern for e-commerce.

- There are a lot of issues with Web Vitals. TTFB is blocking user interaction.

- Looks like SEO (due to SPA) is not being correctly populated?

- It's using Redux (Why??)

- Uses React Classes (Why???)

I'd recommend taking a look at https://nextjs.org/commerce where you can check all recommended patterns from Next.js 10 and more to deploy a successful e-commerce site.

Next.js Commerce supports:

- i18n Internationalization

- Lazy and eagerly loading Images with the Image Component

- Responsive by default

- UI Components

- SEO Ready

- Easily Customizable with TailwindCSS - Themes!

- Data Hooks - to fetch data from your headless e-comm of preference. (BigCommerce support by default)

- Site Speed due to Incremental Static Regeneration and blocking rendering/fallback when needed.

- Auth

and if you deploy with Vercel you have Analytics to stay on track - REAL Web Vitals are key for successful e-commerces.

This means you can easily clone this and run your own store with good practices: e.g https://chicos-commerce.vercel.app/ - Also built with Next.js Commerce.

[+] shanemlk|5 years ago|reply
Why are SPAs bad for e-commerce if they change the URLs? Also I thought Next.js is a SPA framework.
[+] kbyatnal|5 years ago|reply
We thought about using next js ecomm for all the reasons you listed but decided not to because it’s not ready for production use yet. Check out the GitHub repo, there are still a ton of bugs and issues to iron out before you can consider running it for a real store.
[+] holistio|5 years ago|reply
80% of my time I'm doing modern JavaScript development.

A few years ago, I had a tiny studio where I built and sold small webshops.

I have no idea how I'd convince a small customer how this is any better than WooCommerce slapped on a $5 droplet.

[+] anditherobot|5 years ago|reply
Earlier in my career, I used to listen to people making fun of WordPress and PHP. I used to waste time building things with .net or Django, reinventing the wheel, while a perfectly working solution already existed in PHP.

After a while, I swallowed my pride and started to use them. I am not building the next google, or the next Uber. I'm writing projects on the side for small businesses.

Nothing comes even close to the wordpress, PHP ecosystem. Nothing

[+] possibleworlds|5 years ago|reply
Just a personal gripe looking at the commerce.js site... I don't understand why people build these insanely complex spa sites yet put no effort into browser caching and lazy loading media files with correctly sized placeholders / containers. The merchants page has layout jank on every load due to this.
[+] pjmlp|5 years ago|reply
Because they don't know any better.
[+] maxchehab|5 years ago|reply
Why did you choose Netlify over Vercel? Specifically Vercel since they have great DX with the next.js framework.
[+] gkoberger|5 years ago|reply
To be more explicit... Next.js is made by Vercel!

That being said, maybe it's because Vercel already made a Next.js Commerce product: https://nextjs.org/commerce

[+] nomad543|5 years ago|reply
Clicking feedback is very bad, sometimes it's instantaneous, other times it takes a couple of seconds that makes me unsure whether I actually clicked. Product pages loads fast but any other page is a lottery if it's going to load fast or take 2 seconds. Maybe this is a Commerce.js issue.

Is there a way to test the administration pages?

[+] neom|5 years ago|reply
Quick question for anyone using Netlify at work: What's the use case and did you have any issues getting buy-in?
[+] tealpod|5 years ago|reply
AWS admin UI/UX looks like rocket cockpit. Netlify UI/UX is super simple and clean, with Netlify I am sure about what I am doing. Mastering AWS is complete waste of time and talent. And those AWS specialist jobs only exists because of AWS UX confusing and complex.
[+] siquick|5 years ago|reply
The key thing for me was the deployment-per-branch feature, makes testing with internal stakeholders so much easier.
[+] xrendan|5 years ago|reply
Easy for deploying different stages with different build parameters, less of a PITA than the AWS S3 + cloudfront distributions. It's annoying though that we've basically been forced to use their DNS solution since we need custom URLs for branch deploys.

I didn't have any issues with buy-in since we were only a few people at the time and basically got the ok as long as there wasn't any downtime in the transition (which there wasn't).

[+] rudolph9|5 years ago|reply
I have mixed feelings about this example app but I’ve used Next.js in the past and had a really positive experience. The SSR model they use is top notch and a really compelling reason to adopt, among other things.
[+] newsbinator|5 years ago|reply
I'd love to try a Vue/Nuxt equivalent of this, if anybody's looking for a side project idea.
[+] a_imho|5 years ago|reply
Technically all deploys are one click if you disregard the previous X steps that sets up that final click.
[+] vmception|5 years ago|reply

[deleted]

[+] Algomancer|5 years ago|reply
There is a url to a demo store in the github about section.