JSS Commerce parts:
Do you prefer JSS to the more traditional Sitecore MVC approach for commerce websites?
The downside of using JSS for commerce is that you currently need to develop everything yourself. There currently is no JSS storefront, so you will need to build the UI components and infrastructure. This also means that there are a lot of design decisions to be made. For example, how to expose the commerce functionality to the JSS Components, how to share state between components, etc. When you use the SXA storefront, you don’t have to thinks about these kinds of things and can build your own components using the same architecture and patterns as the out of the box SXA components.
Is directly exposing the commerce engine for JSS worthwhile?
At the start of the experiment we were really excited about it, because it gave us a lot of development speed and saved us from dealing with the complexity of Sitecore Commerce Connect. However, at some point the mapping in the API gateway can get quite complex. Especially when you also want to shield Commerce Engine response bodies by doing transformations. Also, tracking commerce events turned out to be more difficult than we initally envisioned. So, next time we decide to use JSS for a Sitecore Commerce project, we would probably decide to create a lightweight REST API and go through Sitecore Commerce Connect.
What do you like most about the chosen Commerce JSS solution?
What is the biggest drawback of the chosen Commerce JSS solution?
As mentioned before, the biggest drawback specifically with commerce JSS is that you currently need to figure out how to connect the different parts of the system and have to custom build a REST API and all the UI components. With JSS in general we found the following drawbacks:
Front-end developer still needs to have Sitecore knowledge
The developers experience on the front-end is amazing. They can work disconnected, use the tools they know and like, etc. However, we found that the front-end engineer still needs to have a core knowledge of Sitecore. For example, when you start building features code-first you need to know what field types there are and when to use which one.
High learning curve of the solution
A lot of new technology and concepts: development modes, workflows, server side rendering.
Lack of guidance and examples
Although the JSS documentation is extensive, it seems some concepts are missing. For example, we ran into this issue that the JSS site was not working in the experience editor (Integrated mode). Apparently this was because some JSS items in our content tree were in the wrong workflow step.
Would you use JSS for your next Sitecore Commerce project?
We would be willing to try it for a really simple e-commerce site with requirements similar to the features implemented by the SXA storefront. In our experience the type of e-commerce sites that choose Sitecore, are quite demanding in terms of functionality and scalability. For example, we know from experience (From building Mercury, a Sitecore Commerce accelerator) how much time it takes to build extensive filtering functionality and would not like to do this in a customer project. If you have to build all this functionality yourself, you will spend all time in the project doing this. Time that you would probably rather spend on features that make a difference, e.g. implementing a proper customer journey.
How much time did you spend on this experiment?
Overall we both (Joost & Jonne) worked on this for 3 weeks. Most of this time was spend on learning JSS and figuring out how to make JSS and commerce work together. Our velocity was amazing, but keep in mind that we kept the scope and problem space as small as possible. This is a really naive shop implementation.
Show me the code?
You got it: Repo on Github