(Yes, I was going for buzz word density in that title!)
There has been increasing talk about concepts like “headless”, “PWA”, “SPA”, “MPA” in the context of ecommerce. In the following I provide a high level introduction to these concepts. (Disclaimer: If you want a deep technical evaluation of the alternatives, this post is not for you.) I then go a little further and talk about the architectural impacts, which can be particularly important if you are currently on a hosted platform where the provider manages your site for you today.
Please note: I mention a number of specific technologies in the following discussion. This post is in no way an endorsement of any of them. I include concrete examples only to help readers to better understand the principles.
If you really want to understand the following terms, I do recommend doing some Google searches and checking out a range of different definitions. The following is the way I think about them, not 100% formally correct definitions.
Headless Commerce: Headless commerce is the pattern of having the customer experience separate from the backend. They communicate via agreed to APIs. Any commerce platform with suitable APIs can then be used as a “headless” backend, even if the platform also supplies a web storefront experience. VueStorefront.io is an example of a headless storefront. It works with multiple commerce backends from different vendors.
Headless is interesting as frontend technologies tend to move faster than backends. By decoupling, your frontend can take advantage of new capabilities faster without waiting for platform adoption. It is also useful to create custom experiences to support special cases, like a sale event. Want to create an app to simplify sending flowers on Mother’s day? Build a streamlined experience in whatever technology you like, integrating with the commerce backend (for tracking orders etc) via APIs. Frontend experiences may be exposed also in different platforms (open web, Facebook, WeChat, in-store kiosk, etc) with all orders coming back to the one unified backend, making tasks such as inventory management simpler.
One consideration if you are considering headless commerce if you are currently on a SaaS platform is who is going to manage your storefront? Are you going to run it yourself? There are venders that support this model as well (e.g. Front-Commerce: PWA frontend for headless eCommerce (Magento 1, Magento 2, OroCommerce, Prestashop, …)).
Progressive Web App (PWA): There are a number of slightly different definitions of PWA (wikipedia, MDN, web.dev), but the fundamental goals are to have app-like experiences on the web. This includes capabilities such as being highly responsive to user input, installable (via a manifest file), and being resilient to failures such as loss of network connection (typically supported using a service worker). Lighthouse can be used to score your level of PWA support, implying a more concrete definition.
Multi-Page Application (MPA): The traditional approach of web development where each new page (with a separate URL) fetches content from the web server and displays the result.
Static site generation can be harder for ecommerce sites with large numbers of product pages or with complex products with multiple product options (sizes, colors, capacity, etc). The goal of static site generation is to create a HTML page for every URL the user will visit as part of a build process for the site. The static files are then deployed to production. For an ecommerce site however you may want to remove a product that goes out of stock, or add a new product that just arrived. Performing a full site deployment typical of static site generators may not be an option. (BigCommerce was exploring this approach with WordPress sites, updating WordPress pages when product updates occurred.)
Of course, you can imagine hybrids for all of the above. For example, for static site generation you might generate pages for the whole site plus a single product description page that takes a SKU on the URL as an argument. The page then performs a backend API call to get product data to use to “hydrate” the page.
Are PWAs always SPAs?
The PWA goals do more naturally align with SPA in my mind. An SPA typically has smoother page transition support, making it feel more “app-like”. SPAs are generally easier to make more resilient to things like network losses (they can cache content locally and use that if the network connection is lost).
If you are in the Magento space, PWA Studio for example generates a site that is a PWA using a React-based SPA framework.
But you absolutely can have a more traditional site where user clicks take you to another page loaded up from a website (MPA), but if there is a network loss a service worker intercepts the request and displays a network loss warning instead. In a normal browser you get an ugly experience. With a service worker the user feels like they are still on the site (with the standard site navigation and look-and-feel).
So both a SPA and a MPA can be a PWA, but it is not automatic. A SPA or MPA without a manifest file (making them installable on a device) is not a PWA.
Headless, SPA, MPA, PWA, … what impact does this have on your architecture? Well, like all deep questions, “it depends!”
For example, how do you host a site? If you are headless, your storefront is not hosted by your commerce platform. So you need to host the frontend yourself. That gets even more interesting if you have multiple experiences but you want them all accessible via the same domain name. How do you route the right request to the right web server? Do you need to create a separate domain name per storefront experience you develop?
Taking VueStorefront as an example, it also depends on a particular backend. The VueStorefront backend includes an ElasticSearch index for product search. This has to be run and maintained, updated by the commerce backend, but it is more a part of the frontend stack.
If you statically generate your site, that can make hosting easier (and frequently more robust from attack as the files can be locked down as 100% read-only in production). But updating the site can be harder.
If you use React with SSR, then you will probably need a Node.js server to perform the SSR. You cannot generate a simple theme and add it to your existing commerce platform if it does not include a Node.js server to host your code on.
So yes, there are a range of confusing options and considerations to work through. It is not always as simple as saying “I think SPA gives the best user experience for the experience we want to develop so we will use that”. You need to think through the architectural implications as well.
“Isn’t this all a solved problem with a single answer for moving forwards?” In my dreams! If there was a clear “best solution” in all circumstances this discussion would be moot. For example, some sites may be more dependent on the speed of loading the first page, others may care more about the experience across subsequent pages. Sites may also have different numbers of products, different update rates on product data, different complexities of product options, and more. It is a complex field without a single “right” answer. My goal in this post was only to help readers understand the difference, not pick the winner.
Here is some further reading:
- Shots fired! WordPress’s Matt claims Jamstack’s marketing is ‘not intellectually honest’ in debate with Netlify’s Matt – WordPress (I will call it more MPA) vs JamStack debate. I think it is especially interesting for an ecommerce site where content is somewhat dynamic. (For example, category pages may show/hide products based on stock levels.)
- Existing platforms can also frequently support more modern technologies without having to go completely headless (the following are not recommendations, just interesting trends):
- ScandiPWA – The First Open Source PWA Theme For Magento –
- Reacticon 3 – Willem Wigman – Announcing Hyvä, the new Frontend for Magento with various twitter threads
- Implement a Progressive Web App on Salesforce Cloud
- How to Use PWA and AMP for User Centered Design, from Shopify (there are also many apps in the Shopify app marketplace that match terms such as PWA and SPA).