Headless vs. Shopify Theme Enhancement

Introduction

Headless or the decoupling approach is a well-established software architecture principle based on ‘separation of concerns’. The architecture of Shopify itself is built using Ruby on Rails, which is an MVC framework – meaning it separates layers for Database management, Business logic and Frontend rendering. That is why it is one of the most beloved ecommerce SaaS platforms currently in the market, as it favors performance over complexity.

A headless architecture is essentially applying the same approach of ‘separation of concerns’ but in the frontend structuring – so that data handling, business logic and rendering that usually occur within the theming template (i.e., standard Shopify template), are all working in isolation and connected to API’s.

The reasons for this architecture are the shared reasons any software design concept favors – efficiency and scalability. Future-proofing the codebase for what may lie ahead on the roadmap & within the team and minimizing the chances of bugs/issues being introduced over time. That can be demonstrated by the following benefits:

• Modularity – By splitting those front-end concerns apart, you are left with a more modular approach and one in which those parts are then interchangeable.
• Distributed Workloads – Multiple people can now be working on that same homepage at the same time without any issues. The content editors can be updating what they need to update, while the layout is being changed.
• Organization – Separating these aspects leads to a leaner, more organized codebase. From a long-term perspective this means time is saved on staff onboarding into the codebase, due to the easier learning curve; and bringing in additional development resources won’t incur overheads due to building specific project knowledge. It also means that there is a reduced risk of bugs being introduced into a snippet of code or ripple effects into future development tasks, because each snippet should have a single purpose.

For headless

Headless is a step forward in terms of the overall architecture of any digital business. It’s a long-term investment, but with immediate gains. The benefits gained out of going headless would be:

• Unrestricted URL Structures – Compared to Shopify, the URL structures are not fixed. This is powerful for SEO and migrating organic ranking for future builds.
• Organization – Harnessing some of the latest frameworks like Gatsby.js to generate static pages and leveraging caching can make the stores feel instant and a state-of-the-art build, which increases trust in customers.
• Unrestricted User Experience – Compared to the restriction provided while using a theme, designing and coding in Headless is limited only to the imagination of the user experience designers. This also leverages the power of having one codebase for multiple stores for future instances, by which updating the codebase reflects the change in all stores. This makes it future-proof as it is easily extended to include more functionalities.
• Content Management – Using powerful CMS technologies like Sanity is very straightforward and can be configured easily for all modules and localization. It also removes the need for page builders like Shogun which improve performance. Additionally, it is a joy for content teams to use something that is built natively for them and it helps them manage digital assets (images, content etc.) in one place. CMS like Sanity is extremely flexible and can be configured to match all the requirements of content management team.
• PWA – Headless can be treated as a Progressive Web App, which especially helps facilitate faster mobile browsing, making the digital store feel like a native app.
• Metafield Hell – Headless also offers flexibility on content management, there will be no need for defining/using metafields as custom information for products/collections/account page can be added straight in the CMS and it will feel native when updating abovementioned content.
• Translation Management – A 3rd party app for translation will not be needed since the translation can be done within the CMS. Adding/removing new translations is easy and also management becomes easier.

Against headless

The main point someone could argue against Headless in 2021 is the non-readiness of the business to absorb such architecture. That would include:

• Tech Lock-In – Going Headless would mean that the storefront(s) and the CMS will be away from Shopify, even though most of Shopify’s offerings like i.e., analytics, would still be intact. The tech would be locked-in within the ownership of the store owner.
• Loss of Front-end Apps – Shopify apps that are currently used to modify or offer a certain type of front-end functionality are lost in the process. They are rather to be consumed via API’s and prominent apps like Yotpo work properly well with headless because they offer API integrations.
• Total Cost of Ownership – Going Headless would mean that the ownership of all of the tech would belong to the store owner, which due to the increased development time and the in-depth customizability that can be built through Headless, the total costs are increased.
• Different dashboard/CMS – Moving to headless build would also mean that shopify admin will be much less used due to content moving to new CMS, Shopify admin would be only used to manage orders/products and everything else would be moved to the new much more flexible CMS

Shopify theme enhancement approach

The Shopify theme enhancement approach proposes that we ‘edit and dev’ to expand the theme to accommodate an increasing number of functionalities. Shopify has done a remarkable job to serve the needs of small to medium businesses, but it has a number of drawbacks that come with it, in the form of limitations to increasingly complex offerings of different types of businesses.

As mentioned in the headless section, Shopify chooses a ‘separation of concerns’ architecture type for handling the backend work, but the same does not apply for the theming part mainly because they are built in a straightforward manner based on a naked approach. The limited possibilities however are for sure trying to expand these stores to multinationals, where good multilingual/multi-currency support are without a doubt the biggest drawbacks. There are third party solution in the form of apps like Langify that can help with translations, but similarly as to why companies are not preferring traditional CMS like Wordpress that can be filled with plugins, continuing to solve your store issues through a stack of third-party reliance that will greatly affect speed, SEO and at times stores can be reliant to the fate of such apps updates.

Nonetheless, clients that have built on Shopify through themes are really happy with the overall experience and possibilities it offers for their store beginnings because of its easy to use and maintain approach. These are some of the benefits that Shopify + themes offer:

For Shopify theme enhancement

To argue the choice to continue enhancing the current theme of Shopify that has been used on the store, mainly boils down to:

• BAU and Familiar Teams – Not having to invest for the future and make updates to the current Shopify theme and a ‘used to’ team that already is familiar with the centralized management within Shopify or editors.
• Loss of Front-end Apps – Front-end modifiers and functionalities earned through third party providers work.
• Less developer expertise – Having most of the functionalities given as part of Shopify, there is a lesser need for development expertise, but this becomes increasingly unavoidable the moment that more complex functionalities (i.e. multiple variants) are required.

Against Shopify theme enhancement

The main cons and arguments as part of continuing to spend on enhancing one’s theme would be:

• Reduced Performance – As mentioned earlier, using standard build templates and requiring the functionality offered by third party apps greatly affects the performance of the store in terms of loading speeds and SEO.
• Restricted URL Structure – URLs of Shopify stores with multiple back-ends will read as subdomains (namely de.nameofstore.com and uk.nameofstore.com, rather than nameofstore.com/de and nameofstore.com/uk) – greatly impacting SEO and handling of multi stores.
• Restricted User Experience – Contrary from Headless, this type of setup is very restricted in providing an ever-growing need for functionality expansion and the only way to provide any type of functionality (i.e., complex variant structure management) is through ‘dirty workarounds’ that are not controlled within Shopify.
• Poor Organization – From a technical perspective, the codebase is the control piece of development and helps to provide a clear structure for any type of project. Shopify does not allow to control multiple stores from one codebase and thus with the increase of presence, the complexity of delivery can become a bottleneck for growth and immensely increase the expenses as for one type of work, repeating is necessary.
• Translations – Very hard to manage properly and also direct/save user preferences.
• Metafields – When you need extra information for a product/collection/page, metafields are used all the time, and managing metafields is cumberstone most of the time.

Key takeaways

In summary, there is a lot to consider around this topic and especially in how best to implement it into a given project. These are the key points to takeaway:

• Headless approach is a positive long-term step if it’s feasible in your context. It is essentially a well-established software design pattern, and a positive thing if in a position of delivering a custom build. It will likely mean extra cost up front for the immediate build, to be more streamlined & flexible and reduce cost into the future.
• Headless serves as an easier way to control expansion to other countries, as there will be only one codebase for tech management and multilingualism is served from only one back end. Contrary from native Shopify, we only need to set up different stores when a different currency is required.
• Native Shopify is more easily handled by ownership, while the Headless approach would require a tech team to be more involved.
• Native Shopify profits from already built third party solutions, while Headless compromises more dev time to build internal solutions for an improved performance.
• Headless uses only one codebase, which is focal and reusable for further projects down the line.