If you follow eCommerce and CMS platforms then you’ve heard of a buzzed-about technology approach over and over again…headless.
Headless Commerce
Headless CMS
Headless Architectures
Headless Systems
|
What Does Headless Mean?
|
At its simplest, headless refers to a software architecture design in which the frontend and backend parts of a website are separate, independent web applications.
Let the backend system(s) handle the logic and data, while the frontend handles the content display.
In between are the APIs.
This way teams on each side can iterate rapidly and independently of the other.
Simple and great.
This is the hope, anyway.
|
|
|
The Benefits
|
Happy Creative and Marketing Teams…
They get rapid simultaneous iteration for frontend design updates and backend content updates.
As well as a larger degree of content management freedom.
Happy Customers…
Websites loads faster and are more reliable.
Websites are more secure with core data safe in the non-web-accessible backend.
Happy Developers…
Much more flexibility in frontend choices, such as standbys like Ruby on Rails or modern Javascript frameworks like React and Vue.
But, let’s get this out of the way…
Headless architecture isn’t the solution to every problem for every brand.
In fact it may even cause problems that you weren’t expecting.
Sometimes this can mean even slow down the types of iteration you were hoping to speed up.
|
|
|
The Realities
|
Speed…
Headless architecture by itself is unlikely to solve all of your site speed problems.
SEO…
Depending on the implementation, SEO strategies can be more challenging to implement.
Content…
Lofty implementations of headless architecture promise full freedom of content design and display.
But in practice it may be difficult to maintain branding standards across teams and applications.
Channels / Integrations…
Headless doesn’t inherently make integrating channels more seamless.
For example, using Shopify in a headless manner may mean losing access to the app ecosystem.
Developers may be forced to build brand new integrations, which could for example slow down the initial integration with a 3PL provider, or make it more difficult to switch to a new ESP.
Now, the good news…
It doesn’t have to be all-or-none.
|
|
|
Our Approach
|
| We believe that brands should take advantage of the many benefits of headless architecture by applying the principles only where they make make sense.
For example, a fashion brand may go partially headless by keeping their shop section running on Shopify while the rest of their brand content is managed in WordPress or Contentful and delivered in React on the frontend.
A hotel brand with no eCommerce may go totally headless with content managed in WordPress and delivered by a minimal frontend system running on Ruby on Rails.
What we do is make our content management experience as simple, intuitive, and flexible as possible.
We enable non-developers to create entirely bespoke experiences without developer intervention and within the branding guidelines of the site.
Hospitality brands, for example, are frequently a good fit for headless.
From room reservations, to restaurant bookings, to spa services, to email marketing – the list goes on – backend systems for hospitality brands are quite often diverse and complex… |
|
Then add in all the individual websites for each hotel, their restaurant websites, and other related websites that all need individual management and you get a better picture of the overall architectural need.
WordPress backend
We start with a Multi-Site WordPress setup for the backend since it is a tried and true Content Management System that has powered a majority of the web for nearly 20 years.
Multiple sites can be managed under one platform allowing for macro and micro management suited for large teams.
Users find it comfortable comfortable and familiar to manage content.
We set it up with simplicity and modularity in mind for as much frontend flexibility as possible.
Elasticache/Redis caching middle layer
These datastores offer ultra-fast data retrieval for the frontend.
They are much faster and more reliable than APIs from WordPress servers or other 3rd parties.
If there are problems with the backend servers, data is safely stored here and the the frontend is undisturbed.
We can easily change format/schema of data here to support frontend needs without requiring updates in the backend.
Ruby on Rails frontend
A robust, fast and easy to work with MVC framework.
We design and build the frontend with curated/branded modularity in mind.
Frontend developers can work independently from backend developers.
With our approach you get the benefits of the headless approach while mitigating or eliminating the drawbacks.
Should you consider headless?
If your brand has a diverse array of offerings that don’t neatly fit into one system, you may want to consider a headless or hybrid headless approach.
You can find the services that best fit your individual needs and your development teams can work independently with modern build systems that can deliver highly performant results.
