Should I go headless on Shopify / Shopify Plus? Pros & Cons of Headless

Send To Pod

Original Article: Should I go headless on Shopify / Shopify Plus? Pros & Cons of Headless

Convert your long form article to podcast? Visit SendToPod

----

---

Headless is no longer the new buzzword in eCommerce (and Shopify). It has been trending upwards for at least the past couple of years and isn’t going away. By this point you will no doubt have read dozens of very similar articles around what it is, and opinions on why it is good or bad, worthwhile or pointless on Shopify - and have seen the word ‘decoupling’ more times than ever before. But a buzzword is still what Headless is. The reason being, it’s not a technical innovation. It’s a well-established software architecture principle called ‘separation of concerns’ - but with a more glamorous spin.

What is Headless

Shopify itself is built using Ruby on Rails, which is an Model-View-Controller (MVC) framework - meaning it separates the layers for Database management, business logic, and frontend rendering. A Headless architecture is essentially applying this pattern into the way the frontend is structured - so that the data handling, business logic, rendering that usually occur within the theming template files are all working in isolation, and connected via APIs.

Data: All of the content being output onto the page. This includes rich content landing pages, blogs articles, product images & descriptions, metafields etc.

Business Logic: The functional behaviour on a page, driven by the Liquid coding within the template. An example of this would be displaying product recommendations, and using Liquid to check any Tags or user interactions before showing the appropriate product selection based on those rules.

Rendering: The visual front-end development work - styling and layout. Everything you see at a wireframe / design / styleguide stage of planning.

The reasons for this change in architecture are the shared reasons any software design concepts are applied - efficiency and scalability. Future-proofing the codebase for what may (or may not) lie ahead on the roadmap & within the team, and minimising 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 which those parts are then interchangeable. For example, switching the layout for a different design inline with a marketing campaign (see the SkullCandy layout completely changed for a new release or campaign), or delivering a different experience to people using devices in-store, to an app or to an optimized storefront for China for example.

• 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.

• Organisation: Separating these aspects leads to a leaner, more organised 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.

• Independent Releases: It was already touched on that multiple stakeholders can work on a page at the same time - eg content editor & developer working on the homepage. Building on this, multiple developers can be working on completely unrelated tasks with the knowledge that there will be no conflicts in the code the...