There are pros and cons to consider when deciding whether to go with a headless Shopify ecommerce solution or a more traditional Shopify-hosted solution, and in this post I'll provide a rundown of my findings after building a React-based headless Shopify site in a recent project.
In a headless Shopify approach, you can build your own site in whatever language and framework you want and allow customers to add products to their cart, a custom cart that you've built, while still on your site. Typically the store is set up so that once the customer enters the checkout flow (typically by hitting some kind of "checkout" button), the customer is taken to your Shopify store to complete the purchase.
Note that the Buy SDK does not offer all of the functionality of the Storefront API. In order to access certain fields, you'll need to build a custom Storefront API GraphQL query. To do this, you'll need to use the Buy SDK's unoptimized build which is quite a bit larger. For a single page app rendered client-side, this will impact page weight and overall page load times :(.
Being able to build a completely custom site and shopping experience is pretty compelling. While Shopify's cart and checkout experience has most likely gone through rigorous UI/UX design reviews, A/B testing, and lots of iterations (meaning it should be effective at leading to conversions), having the option to work closely with a UI/UX interaction designer to build a completely custom cart is a really nice option. While ecommerce is at the end of the day about sales, only you and your team know what's unique about your company and your customers. Perhaps having your own custom cart would lead to even more sales.
The other advantage is in terms of tech stack. Not being tied to Shopify's templating language, Liquid, means you could your site in whatever language and using whatever framework you want, as long as it could talk to Shopify's Storefront API.
If you're into Gatsby, you can use their Shopify plugin and hit the ground running.
If you end up needing to use the Storefront API directly, you'll need to use GraphQL. A lot of developers are already familiar with (or are interested in building with) GraphQL-based APIs. This makes it easy to get started with if you have any level of experience with GraphQL.
If something goes wrong, Shopify support likely won't be of much help. Plan on being able to and adept at troubleshooting your application on your own.
If you cringe at the thought of building your own shopping cart, your own product options picker, or building functionality to check whether a customer checkout is stale, building a headless Shopify solution may not be the way to go. No matter what kind of site you're building, plan on at some point building some functionality that duplicates features that Shopify has out of the box. That's the tradeoff for the freedom of a headless Shopify site.
Another thing you'll need to build in is support for handling any errors that the Shopify API may return, just like when dealing with any kind of API. You don't want to lose sales because of some kind of error.
If you need to store metadata at the product or product variant level, you'll need to use Shopify metafields. For example, you could use a metafield to store a shorter version of a product's name that's displayed in a shopping cart. These can become pretty cumbersome from a data entry standpoint if you have a lot of them. And you must remember to whitelist all metafields in order to make them available to Shopify's API.
The GraphQL API can be considered a con for developers who are more used to JSON-based APIs. However, the Storefront API documentation is decent and there is intro to GraphQL documentation as well. There is also a Shopify Storefront API GraphiQL explorer tool that you can use to test out GraphQL queries on Shopify's demo store.
There are Storefront API rate limits to take into account when building a headless Shopify site. Luckily, these limits do take a user's IP address into account, so surges in traffic (Ex. due to a product launch) shouldn't put your app at risk of hitting up against these limits. Note that if you're on Shopify Plus, the limits are higher.
If you're used to being able to install add-ons to add new functionality (like you can with Shopify and with CMSs like WordPress), you'll be mostly out of luck. With headless Shopify, add-ons that you use on the backend side (within Shopify's admin interface, for example), will usually work fine. But add-ons that rely on you having a Shopify theme will not.
If you're used to frameworks like Gatsby that handle image optimization for you, you're going to be more DIY under headless Shopify. There are some image helpers in Shopify's Github repo that can help you crop images, but there is nothing available that does image transformations for you like Cloudinary or Imgix. You will have access to Shopify's CDN for images, but other than that you're on your own. What you can do is look for other image tools that work on top of Shopify.
While it's likely not officially supported or endosed by Shopify, Imgix does work as a layer on top of Shopify. That would allow you to do things like image cropping, filters, etc. The only caveat is that if you want to replace an image in Shopify you'll need to make sure to rename the file before re-uploading it. The reason is that Shopify doesn't currently have a way to let you purge their CDN cache for a single image URL like Imgix does. Maybe someday! I put in a feature request :-).
There's a lot to consider on both sides of this, and I hope this helps someone out there who's looking into Headless Shopify. Have you built a headless Shopify site? I'd love to hear what you built it with and how it worked out.
Featured image by Lauren Fleischmann via Unsplash