When is Headless the Right Choice?

Over the last year, the headless architectural pattern has exploded in popularity as well as infamy. Developers in ecommerce have varying opinions on the use of headless. Is headless ubiquitous? Should merchants and developers think headless first? What about JAMStack and MACH — do we have to choose between them?

The following are my opinions on the topic. This piece is based on what I have learned from research and the BigCommerce Developer Community.

🏃‍♀️ Quick Aside: Thank you to our BigCommerce Developer Community on Twitter and in our Slack for your assistance. You all are fantastic and I appreciate the candid conversation we had on this topic.

The Ubiquitousness of Headless

I believe the headless pattern to be widely accepted and adopted today. Thus, making it fairly ubiquitous. However, in ecommerce specifically, I think that headless is more infamous than accepted.

The biggest reason I see for resistance to headless, from product teams and engineers, is not due to the architectural pattern itself; it is more than these teams are advocating for a merchant’s businesses. Development teams do not want businesses to incur additional costs when they are not necessary. A merchant’s business can evolve; using the simplest solution can be the right solution now and become more complex as the business grows. Developers are wary of over-developing a solution when it is not called for.

I think it is only a matter of time until headless commerce is considered as mainstream as page builders like Shogun or themes like Cornerstone are. We should see headless as part of our commerce evolution. Headless is techy and innovative to many merchants; I think we have a bit longer before massive floods of merchants ask for headless options by name. We should be preparing for this though, and thinking about our approaches and strategies to help businesses in each stage of their commerce lifecycle. Whether that ecommerce site is a Stencil storefront, a reverse headless implementation, or a fully headless architecture.

Rethink a Headless First Approach

Should we always think headless first? Likely an unpopular opinion, but mine is a firm N-O. I think we should advocate for the merchants’ needs based on the requirements they present. We should leave all the options on the table until determining that headless is the best or only option to deliver what they are asking for.

I wholeheartedly agree with Rupert on this. As developers, we are trusted to provide practical and economical solutions based on the requirements presented to us. We should feel an ethical responsibility to speak up when we feel that solutions are being overengineered.

Choosing Between MACH and JAMStack

If you have not heard the term “composable commerce” being thrown around, well now you have. Composable commerce is the idea that you can use both an omnichannel strategy and a headless architecture that is mostly API-based. You then have an orchestration layer to tie it all together. You are not locked into any platform. Elastic Path published a great article on this and they compare the JAMStack and MACH approaches.

They are very similar. As much as possible, a developer should use APIs to compose a solution. Developers should be as lightweight as possible when developing frontend applications. Engineers should reuse as much as they can. Don’t recreate a wheel if you don’t have to.

The biggest difference is MACH’s hard stance on microservices. JAMStack is open to microservices but does not specifically call it out. It is more of a guideline.

I personally don’t see any reason why the two cannot peacefully coexist. Businesses may have legacy systems that they still rely on, I think it is good to consider and purpose ways to modernize; just not for the sake of using a specific branded pattern of composable commerce.

When You Should Be “Pro” Headless

I think there are many pro’s to headless. However, when you should advocate for headless is different entirely. Here are my thoughts on when you should be pro headless for a business:

• The business is strongly opinionated on the technology stack.
• There are features envisioned that are not capable in any ecommerce platform today.
• Integrating multiple SaaS or on-premises offerings into something completely custom is a requirement of the build.
• Performance is a top priority.
• Speed is pivotal for conversations.
• The user experience design is only achievable by utilizing a Frontend Framework or Library.
• The business has established sites with SEO and CMS so it is a better business decision to go headless.

Essentially, when you require a PSL over a coffee plus. This analogy also should lend advice to when you recommend it to the client. Most of the time you probably just need a regular coffee. Every once in a while you need something special — that is then you pull out the headless option.

The “Cons” of Over-Recommending Headless

I don’t believe there are many cons to the development experience of headless architecture. I do think there are a few downsides to recommending headless when it is not warranted. Other than damaging your reputation, you could be causing yourself to have an excessive workload and the stress that comes with it.

My goal is to always be on the side of the developer, I want you to be happy and healthy in this career. I don’t want you to go home cursing the build that should have been simple and was overcomplicated. As a teacher, I used to say to my students, “When in doubt draw it out.” This applies here too. Draw out the requirements, connect the dots and if all paths lead to headless then go down that path well informed.

My Final Thoughts on Headless, For Now

Headless commerce is here to stay, especially as a form of composable commerce. However, it is not the only path to composable commerce. Using an ecommerce platform like BigCommerce is an acceptable path forward for many merchants and is typically the right path forward in the early stages of the business. When the requirements don’t warrant a headless build and business doesn’t demand it — it is best to take the fastest and happiest path forward. You can always iterate towards a headless implementation as a business grows and becomes more complex.

If you are interested and want to learn more about how to build headlessly on BigCommerce our developer documentation contains a Guide to Headless Commerce. As well, you can get started using Next Commerce, a Next.js and BigCommerce starter application.

This was my take on when to build headless. All statements are my own. Gifs were my choice also. If you want to continue the conversation, mention me on Twitter using @rayeethompson. Until next time, let’s always aim to build bigger and better together.