{"id":10286,"date":"2021-02-05T16:46:57","date_gmt":"2021-02-05T15:46:57","guid":{"rendered":"https:\/\/sii.pl\/blog\/?p=10286"},"modified":"2024-01-30T16:36:08","modified_gmt":"2024-01-30T15:36:08","slug":"modern-frontend-in-e-commerce","status":"publish","type":"post","link":"https:\/\/sii.pl\/blog\/en\/modern-frontend-in-e-commerce\/","title":{"rendered":"Modern frontend in e-commerce"},"content":{"rendered":"\n

Looking at Shopify\u2019s valuation on the US stock exchange or LPP\u2019s (CEE largest retailer, employing more than 20 000 people) approach to its stationary stores, it\u2019s hard not to notice the growing importance of e-commerce. On the Internet \u2013 just as in the real world \u2013 many factors impact our shopping experience.<\/p>\n\n\n\n

UX, design, and performance are the key elements which importance are crucial in both online and standard shopping. Each of these topics is so extensive it could be covered in a separate book. Such has already been written. Therefore, I will try to indicate the most important elements of each of them, within my knowledge. I do not intend to thoroughly analyse each of the raised topics, because I am neither an expert in any of these areas nor the form of the article allows for such a comprehensive study. The purpose of this article is to introduce the developer to the potential problems he or she may face in the main areas of modern e-commerce.<\/p>\n\n\n\n

At the beginning, I\u2019d like to discuss a buzzword that\u2019s becoming more and more talked about, especially in the context of e-commerce.<\/p>\n\n\n\n

Headless e-commerce<\/h2>\n\n\n\n

What exactly is headless e-commerce? It is e-commerce where each layer is implemented independently of each other, and the binder of these layers is their API. From an end-user perspective, the potential difference can be perceived mainly in the performance of the application.  However, looking at the available functionalities, headless e-commerce is no different from \u201cregular\u201d e-commerce. At this point, we can ask ourselves a question \u2013 what are the advantages of headless approach in comparison to traditional, \u201cmonolithic\u201d one?<\/p>\n\n\n\n

Advantages<\/h3>\n\n\n\n

High service performance is easier to realize<\/h4>\n\n\n\n

When building webshops based on the \u201cback-end rules them all\u201d principle, it is much harder to achieve the high performance of an application. It happens because of, among other things, the complexity of the back-end architecture, which must also handle the front-end and the cache layer. On the back-end, we usually use additional caching tools like Varnish, Redis or Elasticsearch to keep the results of individual queries in memory.<\/p>\n\n\n\n

Using headless approach, we can easily generate any subpage as a static one, which view is not dependent on user status (logged in\/guest). Static page makes user wait only for \u201cclean\u201d HTML and CSS to load. For e-commerce, this approach works mainly because in this domain the main significant difference for users is the content of their shopping cart. From an UX perspective, there is no need to download shopping cart along with the content of the entire site \u2013 it can be downloaded dynamically after the user enters the website. That is why static pages are the best solution for e-commerce.<\/p>\n\n\n\n

At this point, a question about cache invalidation may come up. After all, static pages will not update. Here is another good news for those concerned. Modern front-end frameworks such as NextJS or Remix use the  SWR (StaleWhileRevalidate) pattern. In a nutshell, it means that cache invalidation takes place \u201cunderneath\u201d, after a time interval we specify. In the meantime, users get the version of the page saved in the cache. This solution also allows us to resign from Varnish, which simplifies our system and relieves the back-end developers.<\/p>\n\n\n\n

Smaller scope of technologies required from a single developer<\/h4>\n\n\n\n

f the service we are writing is based on a back-end that also renders the front-end, it is practically impossible for a front-end developer not to know the technologies used on the back-end. For example \u2013 when writing the front-end layer in Magento 2, we need to know the structure of the xml file required by Magento, we need to know what entries to add to each xml file and where to place them. In places where in JavaScript we would like to use data passed directly from the back-end, we are forced to understand the entire MVC structure behind Magento. Of course, behind all this comes the necessity of the knowledge of PHP. And this additional overhead absolutely does not compensate for the required front-end knowledge.<\/p>\n\n\n\n

With the headless approach, front-end developer only needs to know the front-end technology. That\u2019s it.<\/p>\n\n\n\n

Greater flexibility in the choice of technology<\/h4>\n\n\n\n

When working on a headless site (whether it is e-commerce or not), we have more freedom over the choice of tools to accomplish the task, whether it is front-end or back-end. The only thing that binds the two layers together is the structure and the way (SOAP, REST, GraphQL) data is transmitted. Looking at the architecture as a whole, back-end is its foundation. From a front-end developer\u2019s perspective, in headless approach, the back-end is an implementation detail. In this case, you can easily replace the technology anywhere or add a new microservice based on a completely different language or framework.<\/p>\n\n\n\n

Ability to develop individual layers independently of each other<\/h4>\n\n\n\n

Because of the flexibility that headless e-commerce gives us, none of the layers are blocked by another. You can easily implement deployments of individual layers, completely independent of each other. This also allows us to easier iterate design changes.<\/p>\n\n\n\n

Disadvantages<\/h3>\n\n\n\n

The need to integrate additional tools<\/h4>\n\n\n\n

In complex systems, we can expect a lot of built-in functionality, such as i.e. analytics or CMS. Of course, this is the cost that has to be borne in case of their implementation in the headless approach. At this point, you have to answer the questions: if the tools available in the \u201cmonolith\u201d are needed, if they are sufficient, if the development will be fast enough and what kind of developers we have at our disposal.<\/p>\n\n\n\n

Summary<\/h3>\n\n\n\n

The differences I have mentioned are the ones that are easiest to indicate. As for the difference in costs, for example, this is hard to estimate. Costs consist of both the size of the team and the time they spend on the project. The size of the team in a headless approach can be exactly the same as in a traditional approach. As for the lead time \u2013 theoretically, it can also be the same in both cases. In practice, however, I noticed that the headless approach sped up development significantly. This was mainly due to smaller overhead caused by the need for back-end knowledge.<\/p>\n\n\n\n

Three pillars of modern front-end<\/h2>\n\n\n\n

It\u2019s time to discuss topics that in my opinion should be addressed when creating a front-end layer. The scope of each of them goes far beyond e-commerce as well as front-end. Below I will try to discuss these points in the context of creating an online shop<\/p>\n\n\n\n

1. UX<\/h3>\n\n\n\n

UX stands for user experience, or what the user experiences \u2013 in this case in our online shop. UX in itself is a broad topic, far beyond e-commerce, but in e-commerce itself, it is an essential element for a high conversion rate.<\/p>\n\n\n\n

Non-responsive design, complicated navigation, impractical positioning of icons, lack of default and widely used keyboard shortcuts (e.g. ESC key to disable a modal), screen \u201cfreeze\u201d when loading particular actions, menu, which takes up practically the whole page when hovered over, so it is impossible to \u201cunhover\u201d it, no possibility to return to the same place on the list of products after entering a single product \u2013 these are just some of the UX sins, of which at least one can be found in every online shop.<\/p>\n\n\n\n

While in most cases, one or two errors do not cause a disaster, their accumulation can be critical. In extreme cases, it can lead to an increase of up to 73% in the number of users leaving our website (https:\/\/baymard.com\/research\/ecommerce-product-lists<\/a>).<\/p>\n\n\n\n

Filtering on product listing<\/h4>\n\n\n\n

Filtering on the product listing is one of the critical points of our application. The last thing we want to show the user is a screen without any product. Of course, UX in this case has to be just as good on desktop as on mobile screens<\/p>\n\n\n\n