Author: Astound Careers
Ivan Khartov has been working as a front-end developer at Astound Commerce for four years and in the overall sphere of front-end development for around nine years. In his article, Ivan will introduce you to the core differences between traditional Salesforce Reference Architecture (SFRA) and headless architecture, the benefits and key advantages of headless implementation, and the necessary knowledge to implement a storefront head.
Before proceeding, it is important to understand the definition of storefront in the framework of headless architecture. Storefront is an ecommerce service, allowing brands to advertise their products and generate transactions. In traditional architecture, an ecommerce storefront is inseparable from the platform; changes cannot be made without affecting the back-end. In other words, a change made on the front-end also requires a change to be made on the back-end and vice versa. The back and forth consultation is done to ensure a well-functioning service in accordance with the product requirements. From the perspective of a front-end developer, this creates certain challenges and restrictions, not allowing one to use all the available modern solutions.
A storefront for headless commerce is a self-contained web storefront that’s completely separate from the ecommerce platform and any other back-end application. The independence of a headless storefront provides more flexible and innovative solutions, where all communication with the back-end happens via API.
Currently, there are three main approaches during solutions development: commerce-led, experience-led, and API-led. API-led can also be referred to as “the new way” or “headless ecommerce.”
The commerce-led model provides solutions for effective order management; however, it cannot react quickly to any dynamic changes or to consumer behavior. Aside from that, the inner interfaces’ functions are limited, preventing improved experience with the content.
The experience-led model separates the platform from the presentational layer. In this case, the content management system maintains accessibility, playing a major role. Both of these approaches cause limitations. Since the back-end and front-end are bound to each other, implementing any changes in your solution is difficult and slow. This limits opportunities and causes unnecessary challenges for any upcoming initiatives.
The API-led model, or headless model, allows the ecommerce platform and the content management system to cooperate with the user interface, or storefront, via API. This grants far more flexibility and freedom to implement innovative solutions faster and with higher quality.
When directly comparing the traditional storefront to the headless storefront, Ivan says there are three key differences:
Now that we’ve discovered the key differences between traditional and headless ecommerce, we can focus on the technologies required for implementation. The structure of the technological stack for the development of a new product might add additional work within the frame due to the abundance of factors and variables, which should be considered.
Here’s an overview of the three main frameworks: React, Vue.js, and Angular. The graph below displays demand for these frameworks over a five year span, as reported by Google Trends.
It is preferable to work with the framework you are already familiar with. If you are not familiar with any of them, you could select one by observing the information in the diagram below. From the presented chart, it is apparent that the preference for React has been greater than Angular; however, Vue.js is gaining popularity.
React has the lightest production size, which shall increase the speed of any solution; Angular weights the most since it is a robust framework by itself, while React is simply a library. Vue.js is balanced between the two (and proves to be quite easy to learn) while providing the benefits of Angular, which is far more challenging to adapt to.
There is no “correct” option here; however, it is important to consider the indicated data. Select the framework you are most comfortable with, yet if you are unfamiliar with any, begin with the easiest. Even though Angular is a fully functional framework, it is quite difficult when Vue.js is easier to understand and yields the same useful tools.
Keeping the following abbreviations in mind will also be helpful for front-end development. What is SPA, PWA, CSR, or SSR?
A single-page application is a site with a page that updates dynamically instead of downloading the data from the server. In such cases, all the necessary code for the web application (HTML, CSS, JS) needs to be uploaded once. After that, all the contents and elements of the web application update automatically, without any further requirements to restart the browser. This allows a faster load of the web application, reducing the traffic between the server and the browser. Facebook, LinkedIn, Netflix, and Gmail are all examples of a good SPA.
A Progressive Web App is more like a set of guidelines and checklists, rather than a specific architecture. A PWA is famous for and differs from a SPA via the following characteristics:
Server-side rendering (SSR) generates the entire HTML for the page on the server in response to the navigation. This allows smoother processing of the templates and contents for the client. Benefits include a faster initial loading time of the page compared to SPA or CSR applications, no negative effects on SEO, and elimination of additional loading requests that occur during the initial load of the page to the server. However, the higher requirement of resources during each page’s load is a drawback.
In the context of developing ecommerce storefront solutions connected to SEO and the interface, it is necessary to use SSR. But what can be done if the application (SPA) is written on React or Vue and only uses CSR? In such a case, the universal SSR framework comes in handy.
What is a universal JS framework? Nuxt and Next are described as the “universal JS frameworks,” meaning they simply support universal rendering.
Nuxt is a framework for universal applications that is based on Vue. It handles all of the configurations to set up a server-side rendered Vue application.
Next does what Nuxt does, but for React applications. It is a framework for building universal applications that leverage React.
Instead of an out-of-the-box node application, Nest introduces annotations, best practices folder structures, and associated concepts. All additions that you may be familiar with if you’ve used technologies like Spring for Java.
The next tool, which is very useful for successful headless implementation, is Storybook, the tool that allows you to work without a backend. It will enable you to test and document every required component. Storybook will document all changes as they are made, allowing for far smoother cooperation between front-end and back-end developers, quality assurance engineers, and other teams. The tool also allows you to add any preferred add-ons, for example, the one on accessibility which runs on specific parameters and roles, detecting any errors or sections requiring adjustments. This will allow you to build a site entirely independent from the back-end.
The main concept is that the storefront design and all its components can be dissected down to atomic bases. In this case, an atom is a button; a molecule is a button with either a label or an animation; an organism is a larger body of the page, either a header, while the menu is a completely separate organism.
What are the benefits of Atomic Design? Atomic Design can require a lot more thought and planning, but it’s often worth the extra effort. Here are some of the benefits of using this type of design:
This tactic and approach work optimally with Storybook, especially when constructing a headless storefront. Overall, this results in a more efficient timeline, where more effort is invested in improving the front-end content, and you as a developer are freer to make all the necessary changes right away. Sometimes it can take weeks to see the effect of your work on the content, which could also affect motivation. With headless architecture and the tools and approaches mentioned above, you can develop all sorts of solutions comfortably and in the way you prefer.
When should you consider going headless? The headless approach requires specific changes. It is important to answer the following questions before taking action:
Once you have established solid answers to the above questions, you may then consider going headless, finding more adaptable and flexible frameworks for your front-end developers, benefitting the performance of your solutions, and providing higher quality products to the consumers.