CommerceLayer is an incredible headless e-commerce system that we have used extensively over the last couple of years to develop custom e-commerce solutions. The issue with CommerceLayer, however, is that even though the backend functionality and API’s are powerful and extremely easy to use, the frontend tools provided out-of-the-box are not necessarily adequate for many use cases. And while CommerceLayer has made amazing progress with their new App Elements platform, customization remains tedious and, over time, can become quite overwhelming due to the complexity of having to manage various repos, as well as keep on top of underlying dependencies.

A better solution, in our view, is to connect the CommerceLayer API to Retool, which is the leading low-code tool for quickly developing internal software dashboards and apps. Once you connect CommerceLayer to Retool, you gain access to all of Retool’s components and functions to build highly customized apps both for desktop and mobile.

Some of the benefits of connecting Commerce Layer to Retool include:

• Easy customization of data display via drag and drop Retool components, with no need to fotz around with React, or CSS libs.
• Quick integration of other connected 3rd party APIs so you can display all your necessary data in one app with little coding.
• Fast development of serverless functions so you can supplement data from Commerce Layer and even update this data as needed.
• Less painful upgrades, as Retool managees all the necessary dependencies and components for you, allowing to focus on getting the data you need and displaying it how you want.
• Simpler management of user auth by leveraging Retool's own internal user roles and functionality.
• Painless development of mobile apps that will delight your customer service reps.

The bottom line is that Retool provides a faster, and more scaleable platform for data from 3rd party API's, making Retool the ideal frontend for your Commerce Layer data.

We have a created a short demo video below to show what we have done to create some internal apps. In addition, we have included some screenshots below to demontrate the mobile app we have built with Retool and our Commer Layer integration.

If you are interested in setting up a Retool + Commerce Layer integration for your store, please contact us.

Screen Shots Showing a Mobile App Built with Retool + CommerceLayer Integration​

When you want to start a new React project, the docs at React Dev suggest Next.js, Remix or Gatsby. These are heavy platforms, though, which come with alot of extras that you probably do not need, if you are coding a basic client side application, or more importantly if you are just experimenting with React. It's strange that Facebook, that maintains React, suggests these platforms, when they have their own homegrown platform, Docusaurus, which is easier to use, at least for smaller projects.

Install Docusaurus and Begin Coding and Sharing Easily​

So actually, I think a better option to use is to just Install Docusaurus. Then you can use the Docusaurus React Page to code in React. Any feature of client-side React (as opposed to the new RSC, i.e. React Server Components, or Server Actions), can be used easily and seamlessly. For interacting with third-party APIs, you can just use useEffect or something like useSwr.

For coding and testing, you can of course to just code locally, but the great thing about Docusaurus is that it's trivial to publicly publish Docusaurus with any of the major hosting companies, like Cloudflare or Vercel. So you have an easy way of sharing your code publicly. A final added benefit, is that you also have a blog and documentation functionality built-in, in case you want to further market or explain your code.

Bonus: Code in Replit​

Replit.com is an amazing coding platform that you can use instead of installing anything locally. It allows you to code anywhere and forego the massive pain of installing packages on your local machine.

To use Docusaurus Replit, you need a .replit file with the following run command (assuming you are using NPM),

run = "npm run start -- --port 8080 --host 0.0.0.0"

For yarn it is:

run = "yarn start --port 8080 --host 0.0.0.0"

I just turned 50 years old.

It's hard to believe that I took up coding only a mere 4 years ago, when I turned 46, at the start of Covid. With nothing to do during the lockdown, I decided to learn Javascript and React and transition all my websites to Gatsby and then Next.js. I worked with an amazing senior developer, Stan, back then, who I found by accident on Github. I learned a tremendous amount from Stan and still use most of the code he programmed on my production websites.

In hindsight my decision to transition away from monolithic platforms, like Wordpress, was not a great business decision. Coding is hard, and learning to code at 46, with 2 young children and a full-time business to run, is even harder. Coding is a never ending process of making mistakes, refactoring, and constant tweaking. It is extremely time-consuming. Ultimately, you end up sacrificing other aspects of your business to focus on coding.

However, I have yet to find an intellectual activity that is more satisfying than coding, and I have always held firm to the belief, that life is about learning. There is no greater joy than intellectual satisfaction, and coding gives you that in spades, which is probably why it's so addictive.

So after 4 years of learning to code, I'm happy to share my first pull request an implementation of the new Shopify Customer Account API on the Next.js Commerce repo. This pull request will allow anyone to use the new Shopify Customer Account API to login customers into their Next.js Commerce website, and eventually to perform critical customer actions, like review past orders, add addresses etc. I felt like this is a great addition to the Next.js Commerce repo because authentication remains a challenging part of any React application. The new Shopify Customer Accounts API, however, greatly simplifies authentication for headless platforms, and easily allows you to pass the logged in user to checkout.

The code for this pull request is admittingly not really too original, as it is based on Shopify's own Customer Account API implementaion on their Remix Hydrogen store and Shopify's docs. However, refactoring this code to use Next.js App router with RSC's, middleware, and server actions was a bit challenging. I did have to do quite a bit of searching and code tweaking before settling on, what I think is the best way to implement the Customer Account API on Next.js.

Of course, this pull request is not totally complete. I still have to actually implement order history, address creation etc. But, I think the current code does provide a reliable starting point for integrating the new Shopify Customer Account API into your Next.js project. Certainly, I look forward to getting feedback on the code, so it can be improved.

The actual code can be found on the this forked branch of Next.js Commerce. Documenation for setting this up correctly, can be found in our Create a Headless Shopify Site with Next.js Docs

Shopify is building their own headless solution, known as Hydrogen, on top of the React Remix framework, which Shopify acquired back in 2022. Remix is a competitor to Next.js and differs in certain respects, though both are ultimately just React frameworks. A critical decision is which platform to use for headeless development? Why not just use Shopify's Hydrogen based on Remix instead of Next.js?

This is an excellent question and I'll spend this post discussing our reasons for opting to use Next.js, at this point to build a storefront, rather than Hydrogen/Remix.

First of all, I'll state at the start that both Remix and Next.js are excellent platforms and either is great option to build a headless store. With that being said, here are the reasons why Next.js, at least at this time appears to be a better framework choice:

Strengths of Next.js over Remix​

• Next.js is more Popular By any standard Next.js is the more popular framework for React, and going with the leader is generally the better option for production deployments because of the ease of support. For example, for virtually any issue you will face in Next.js you can almost always find a solution online or easily find a skilled Next.js developer, or better yet use ChatGPT (the LLM's are better at Next.js simply due to the larger volume of information for Next.js which available for training).

• Next.js is more Powerful With the advent of Next.js App router and Next 14, Next.js essentially took all of the best features of Remix and just turbocharged them, for lack of a better phrase. Instead of the Remix loader pattern, for example, Next.js now has React Server Components. Of course, I don't want to imply that RSC is the same as a Loader, but the coding pattern is similar and RSC's are light years ahead of a Loader in Remix, in terms of functionality. Next.js also has middleware running on Edge (powered by Cloudflare), Server Actions for forms (again one upping Remix, where the form functionality was previously superior to Next.js), and quite simply a better setup for standalone API routes. All in all, it seems to me that Next.js is currently a much more powerful framework that allow for much greater customization and scale.

• Next.js is more Versatile While both Next.js and Remix both now push more for server-side functionality vs the browser, the reality is that in any React app, you will need a substantial amount of client-side code. While slightly more complex now on the App router, it is still relatively trivial to build client-side apps on Next.js using your tool of choice, like Tanstack query. On Remix, it not so easy, and as of the date of this post, better client-side tooling is a just an RFC on Remix

Change and Portability​

Of course, all of the above may change rapidly in the future, as Remix now has substantial support from Shopify, and may far outpace Next.js in a few years. At the same time, it's also entirely conceivable that at some point some other framework, will oust both Next.js and Remix (unfortunately React frameworks have a tendency to go in and out of favor quite quickly). In fact, we are already investigating using other React platforms, like Docusaurus (which this website is built on), to build out a complete e-commerce solution. Stay tuned...

However, if you build with the Next.js App router and stick to edge functions in Next.js, I don't believe porting code will be all the difficult as Next.js App router and edge is more and more attuned to the fundamental Web APIs that you can find on MDN, like Remix has always been (see Why I'm Using Next.js). It is much easier to port standard Javascript code to any new platform. In fact, it is somewhat easy to port code from Remix to Next.js, again if you stick to the App router and Edge functions. So I don't think you lose anything by using Next.js, and all the code will be easily portable to any other framework.

Why did Shopify build on Remix?​

To close out this post, I want to address an interesting question. If Next.js is seemingly the better platform, why did Shopify decide to build Hydrogen on Remix, as opposed to Next.js? I believe there are two answers this question: the timing of technology releases, and more importantly critical business considerations.

Technology Timing​

Initially, Shopify attempted to build their own React framework, using RSC, to power Hydrogen. This failed. When it did, I imagine Shopify did consider using Next.js, and may have even attempted to buy Vercel (the creator of Next.js). However, back in 2022, Next.js hadn't yet released a stable version of the App router (still as of this post, the App router has some glaring issues, mostly around cache), and so it's doubtful Shopify saw any benefit in building Hydrogen on top of Next.js Pages router. Of course, the Pages router is stable and proven, but it's tough to see any benefit of Pages over Remix, and in that contest, I'd say Remix has an edge. So, in this respect, the decision to use Remix was more of a timing issue, more than anything else. Would Shopify use Remix now when the Next.js App router is stable? From a purely technology perspective, I'd say the answer would be a resounding no, because Remix is in all respects behind Next.js at this point. However, technology is never the only consideration. There are critical business reasons why Shopify would never build on Next.js, unless they could buy them.

A Business Decision to Maintain Control​

The reality is that Shopify simply cannot rely on Next.js as the underlying platform, as they want complete control over the entire headless experience. Next.js is managed by Vercel, and despite claims to the contrary, for the best experience with Next.js in production, you must host by Vercel. There is no way Shopify would cede the hosting of their headless platforms to Vercel. As it is now stands, Shopify will also claim you can host Hydrogen anywhere, but the reality is that it is built for their Oxygen hosting platform, and if you are going the route you should host with Shopify Oxygen.

Furthermore, how could Shopify rely on Next.js to prioritize platform issues that relate to Shopify stores? They can't. The only way Shopify can make sure a framework is meeting its needs is to own the platform outright.

So in the interest of controlling the entire headless ecosystem, Shopify had to buy a framework, and pour resources into it. Since Vercel as apparently not for sale (or not at the price Shopify was willing to pay), Remix was really the only other mature platform in 2022 that was available, and so that's what Shopify bought.

Was it the right decision? Time will tell. But it doesn't really matter, as Shopify ultimately doesn't care which React platform you use, as long as you use Shopify as the product CMS and checkout. Of course, internally, they will and can only really focus on Remix now, but as Remix code is basically just React and standard Javascript, you don't have to use it, and it seems like a better choice to just go with the more powerful platform, Next.js, and hope for the best.

The technology driving e-commerce is rapidly changing with the advent of e-commerce solutions, like Shopify Hydrogen, that separate backend functionality from the frontend tooling. This trend is generally called "headless" commerce. I don't particularly like the term, headless commerce, but will use it for the remainder of this post, simply because it is an accepted industry definition for this type of commerce set up.

The problem with headless e-commerce is that even though it offers exciting possibilities, it remains complex and difficult to implement. This is partially due to the fact that headless commerce is relatively new, i.e. Shopify only bought Remix in 2022 to accelerate the development of Hydrogen. However, the difficulty with headless is also related to the fact that most headless solutions are built in some sort of Javascript script framework, like React, and Javascript frameworks are notorious for changing things up way too frequently. This leads to too many solutions to the same exact problem, and way too much much code refactoring, making it nearly impossible to develop themes that can stand the test of time.

Our goal at DaliCommerce, Inc. is to make the transition to headless commerce easier by providing a full suite of services based around core technologies that we believe will stand the test of time, given their wide acceptance, their use of core Javascript Web Standards, and the standardization of their platforms.

We are focused on three main areas:

• Frontend e-commerce themes based on the Next.js App Router and powered by Shopify.
• Serverless functions running off of Cloudflare Workers (Note: Next.js Middleware and Edge API routes both run on Cloudfare Workers).
• Admin dashboards in Retool, which is an amazing tool to quickly build admin tools based on the technologies above.