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

Terminology

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. 

Single Page Application (SPA): A web SPA is where the web experience is implemented as a JavaScript application that is run in the browser. It updates the current document via API calls, resulting in near instant page transitions (the screen does not go blank until the next page is downloaded, like typical web pages). This makes it feel much more like a native app to users. It does however require a more powerful device and can suffer from longer first page loads, although techniques like Server Side Rendering (SSR) can help. Note that a good SPA can update the current URL and browser history, so it can act like a normal site (e.g. you can share a link or go back in the browser history) even though it is not doing a page load from the web server for each “page” the user sees.

Frameworks such as React/Next.js, Vue/Nuxt.js, Angular, and <insert your favorite here – there are SOOO many of them!> are frequently used to create SPAs as they implement much of the leg work, including SSR support. SSR is where the web server generates the HTML for the first page so it can be rendered faster on first page load, with JavaScript being downloaded for the rest of the site experience in the background. This approach can make the page appear faster, but can still have a delay until the first page is fully interactive. Many of the frameworks use a Virtual DOM that is updated by creating a new render of the page, then making the browser swap over to the new HTML. Svelte is another interesting approach which uses compile time techniques to reduce the runtime effort in the browser.

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.

JamStack / Static Site Generators: Another approach is to statically generate a site in advance. It can still use the JavaScript libraries such as React and Vue, but the goal is to serve up static HTML files as much as possible for requests.

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.

Architectural Impact

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.

Conclusions

“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).