The Shopify POS suite is a key component of Shopify’s Unified Commerce approach, enabling merchants to create rich omnichannel experiences that bridge their offline and online shopping channels. Initially launched in 2013, Shopify has continued to improve its POS hardware over the years, making it more powerful and expanding availability to [more countries.](https://www.shopify.com/editions/summer2024#pos-in-more-countries)

What sets Shopify’s POS lineup apart from the competition is the flexibility merchants have in designing their POS setup, with various [card readers](https://www.shopify.com/pos/store/collections/card-readers) for different environments and the ability to connect a [cash register](https://www.shopify.com/pos/store/collections/cash-drawers), [barcode scanner](https://www.shopify.com/pos/store/collections/barcode-scanners), and [receipt printer](https://www.shopify.com/pos/store/collections/receipt-printers-and-paper) optionally.

In terms of functionality, while Shopify’s POS system comes with [a rich set of native features](https://www.shopify.com/pos/features), Shopify also offers the ability to customize the POS system using Apps. The Shopify App Store already features [200+ POS apps](https://apps.shopify.com/app-groups/extensions/point-of-sale), offering product bundles, loyalty programs, and retail staff management features.

Still, if these apps don’t cater to your needs, you can develop your own POS UI extension—a trend becoming increasingly popular as Shopify starts serving larger merchants with more sophisticated requirements.

In this article, we will show how to do exactly that: by taking inspiration from a real-world scenario, we will build an end-to-end Shopify extension that allows your customers to show a QR code while completing in-store purchases to connect the purchase to their customer account. This eliminates the need for a store associate to look up the customer by their name or email and creates a nice “wow” moment for the customers.

Let’s get started!

## Creating Our Shopify App

Before we can get started building our extension, we will need the following:

* A working Shopify partner account
* The Shopify CLI running on our machine
* A development store with the [Checkout and Customer Accounts Extensibility developer preview](https://shopify.dev/docs/api/release-notes/developer-previews#checkout-and-customer-accounts-extensibility-developer-preview)

Once we have everything, the first step is to create a new Shopify App that will expose our custom functionality:

```
$ shopify app init
```

The CLI will ask what type of app we want to build. We need a Custom App since we’re building functionality specific to our store and not an app for general distribution.

Once we have our custom app, we must understand what [app surfaces](https://shopify.dev/docs/apps/build/app-surfaces) we want to hook into. In our case, we’ll need:

* A [Customer account UI extension](https://shopify.dev/docs/apps/build/customer-accounts) to show a customer their QR code in our online storefront.
* A [POS UI extension](https://shopify.dev/docs/apps/build/pos) that will allow store associates to scan the QR code to identify the customer.

Let’s start with the first one!

## Displaying the QR Code in the Storefront

Run the following command to create our Customer Account extension:

```
$ shopify app generate extension --name loyalty-card
```

When asked what type of extension to generate, select Customer account UI extension. The CLI will also ask whether we want to use JavaScript or TypeScript--we’re going with plain JavaScript for our example, but feel free to use whatever works best for you!

By default, the generator will create a `FullPageExtension.jsx` and a `MenuActionExtension.jsx` file as examples. We’ll want to remove them, along with their corresponding configuration in `shopify.extension.toml`, and replace them with a new extension:

```
# ...

[[extensions.targeting]]
module = "./src/LoyaltyExtension.jsx"
target = "customer-account.profile.block.render"

# ...
```

In `LoyaltyExtension.jsx`, we’ll write the code to render our QR code on the customer profile page. In this example, we’re generating the QR code with a free API, but we could use our own server (also, Shopify will support a [QRCode component](https://shopify.dev/docs/api/checkout-ui-extensions/unstable/components/other/qrcode) soon):

```
import { Heading, Text, View, BlockStack, Link, Card, Image, reactExtension, useApi } from '@shopify/ui-extensions-react/customer-account'

function LoyaltyExtension() {
  const { authenticatedAccount } = useApi()
  const customerId = `gid://shopify/Customer/${authenticatedAccount.customer.current.id}`

  return (
    <Card padding="small">
      <BlockStack spacing="tight">
        <Heading>
          Your Loyalty Card
        </Heading>
        <Text>
          Scan it in the store to earn points!
        </Text>
        <View maxInlineSize={128}>
          <Image source={`https://api.qrserver.com/v1/create-qr-code/?size=300x300&data=${customerId}`} />
        </View>
      </BlockStack>
    </Card>
  )
}

export default reactExtension(
  "customer-account.profile.block.render",
  () => <LoyaltyExtension />
)
```

While this looks like an ordinary React component, we won’t be able to import assets like images or use regular HTML tags. This is because Shopify renders the UI using its native engine. As a result, the styling of our extension is limited to the Components API and the brand styling inherited from the store.

With everything set up, we can test our extension by running:

```
$ shopify app dev
```

As part of this command, we must select a partner account and development store to test the app.

With the command running, we can preview our customer account UI extension by pressing P on our keyboard. The Developer Console will open up in our browser with a link to preview the extension. Clicking the link should show our QR code:

![](https://cdn.sanity.io/images/kqgmf0g2/production/300b8ad677bf19e7245ab3bac52ab4a91ac96284-1214x1390.png?fit=clip)

With the customer account UI extension working, we are halfway there. Customers can view their loyalty cards, but there is no way our staff can scan them just yet. Let’s see how to do that!

## Reading the QR code in the POS

To create an extension capable of scanning QR codes, we need to set up a POS UI extension that interacts with the barcode scanner and sets the customer on the current order when a customer QR code is detected.

Since this extension is part of the same feature we were working on earlier, we will generate the extension under our existing app:

```
$ shopify app generate extension --name loyalty-card-scanner
```

Even though POS extensions are set up similarly to customer account extensions, we need to do a bit more work. In the case of our POS extension, we need two components: 

* A tile that can be added to the home screen of the POS system.
* A modal that is opened when the tile is pressed.

(If you’re curious, you can find all possible targets for POS extensions [here](https://shopify.dev/docs/api/pos-ui-extensions/unstable/targets)).

Let’s start by creating the modal since we’ll need to use it in the tile. Create a file called `Modal.jsx` with the following contents:

```
import { Screen, Navigator, reactExtension, useScannerDataSubscription, CameraScanner, useApi } from '@shopify/ui-extensions-react/point-of-sale'

function Modal() {
  const { cart, toast, navigation } = useApi()
  const { data, source } = useScannerDataSubscription()

  // This runs on every change to `data`.
  if (data?.startsWith('gid://shopify/Customer/')) {
    const id = parseInt(data.split("/").pop())
    cart.setCustomer({ id: id })
    toast.show(`Found Customer: ${id}`)
    navigation.pop()
  }

  return (
    <Navigator>
      <Screen title="Scan Customer Loyalty Card">
        <CameraScanner />
      </Screen>
    </Navigator>
  )
}

export default reactExtension(
  "pos.home.modal.render", 
  () => <Modal />
)
```

Hopefully, the code is pretty self-explanatory:

1. We render a screen with a single `CameraScanner` component.
2. We use `useScannerDataSubscription` to listen for scanner data.
3. When our QR code is detected, we set the customer on the cart, show a toast, and close the modal.

Now that the modal is in place, we must implement a tile component allowing store operators to access it. This is quite straightforward! Just create a `Tile.jsx` file with the following contents:

Now that the modal is in place, we need to set up a grid tile to open it when clicked.   

```
import { Tile, reactExtension, useApi } from '@shopify/ui-extensions-react/point-of-sale'

const TileComponent = () => {
  const { action } = useApi()
  return (
    <Tile
      title="Add Customer"
      subtitle="Scan customer loyalty card"
      onPress={() => {
        action.presentModal()
      }}
      enabled
    />
  )
}

export default reactExtension(
  "pos.home.tile.render", 
  () => <TileComponent />
)
```

Tiles are interesting and offer much functionality out of the box; for instance, their API allows them to be dynamically enabled and disabled. You can learn more about them in [Shopify’s documentation](https://shopify.dev/docs/api/pos-ui-extensions/unstable/components/tile).

Now that we have our components, we must ensure our app knows where to render them. Add the following to `shopify.extension.toml`:

```
# ...

[[extensions.targeting]]
module = "./src/Tile.jsx"
target = "pos.home.tile.render"

[[extensions.targeting]]
module = "./src/Modal.jsx"
target = "pos.home.modal.render"

# ...
```

Unlike with customer account UI extensions, we cannot test POS UI extensions in the browser. Instead, we’ll need to download the POS app to a supported device, like a smartphone or tablet, that can scan QR codes.

Once we have the Shopify POS app on our device, we can run `shopify app dev`, press P, open the Developer Console, click on the “View Mobile” button, and scan the QR code with our mobile device. This will enable the developer preview for our extension on the device:

![](https://cdn.sanity.io/images/kqgmf0g2/production/2cf428d978c9b39006009b01c7d47aa865c16389-1874x342.png?fit=clip)

That’s it! Now that our custom app is fully working, it’s time to deploy it.

## Deploying the Custom App

Now that both extensions are defined and we are happy with the solution, we can deploy our app. By deploying the app, we make it available to the production stores under the same Partner account.

Since the app with our extensions satisfies [the requirements to be hosted by Shopify](https://shopify.dev/docs/apps/build/app-surfaces#hosting), all we need to do is run the following command:

```
$ shopify app deploy
```

Once the app is deployed, we can install it in our store through the Partner portal.

After installing the app, we need to add our grid tile to the POS home screen to our POS home screen and the Loyalty Card app block to our Account Profile page. Once the changes are published, our customers can find their loyalty card on their account page, and our associates can scan the QR codes via the POS.

## The Sky’s the Limit!

With just a few lines of code, we’ve leveraged Shopify’s customer account UI and POS UI extensions to create a smooth loyalty program experience for our most engaged customers. However, there’s so much more we could have done:

* We could retrieve and display a customer’s loyalty status and other data in the POS UI, helping store associates personalize the shopping experience.
* We could allow customers to add their QR code as an item to their Apple Wallet for an even easier (and cooler!) experience.
* We could apply dynamic discounts to the customer’s cart when they scan their QR code based on their shopping history or other parameters.

The only caveat is that we must stick to Shopify’s [APIs](https://shopify.dev/docs/api/pos-ui-extensions/2024-04/apis) and [UI components](https://shopify.dev/docs/api/pos-ui-extensions/2024-04/components) to achieve our goals. While this seems a limitation at first, it has some very appealing advantages: our POS UI extension, for instance, will work smoothly on *all* POS setups, from a single iPhone running the Shopify POS app to a fully-fledged setup POS Terminal setup with a tablet and external barcode scanner.

As Shopify adds more and more extension targets and capabilities to their APIs and UI components, brands will be able to achieve even more with even less--a badly needed superpower in today’s competitive consumer landscape. 

If you have a POS UI or other kind of UI customization in mind for your Shopify store and need help launching it, feel free to [reach out!](https://nebulab.com/contact-us) We’d love to help.

How To Build Your First Shopify POS UI Extension

A couple of weeks ago, Shopify released the [Summer ’24 Edition](https://www.shopify.com/editions/summer2024). Since its humble beginnings in the [summer of ’22](https://www.shopify.com/editions/summer2022#audiences), Editions has evolved into a major biyearly marketing initiative the Shopify team uses to update their customers and the larger commerce industry about the latest product announcements, upcoming functionality, and the general direction the platform is taking.

The splashy landing pages are then coronated by several official events, earned media (including, yes, the very article you’re reading), and fringe industry gatherings aimed at creating more hype around the platform and, by extension, the hundreds of industry players that live in its shadow and participate in its ecosystem.

And since everyone and their dog has an opinion on Editions, we thought we’d be remiss not to share our take on the most exciting announcements.

In the following paragraphs, you’ll find a recap of our favorite announcements from the Shopify Summer ’24 Edition, along with our opinions on what they mean for the future of the ecosystem.

Let’s get into it!

## You Get a Market, You Get a Market, Everybody Gets a Market

Historically, internationalization on Shopify has been challenging. For a long time, brands that wanted to start selling in other countries were forced to set up expansion stores that were, effectively, completely independent of the main store. This forced brands to sync their product catalog, settings, inventory, apps, etc., across all their stores–a Sisyphean task that often required installing clunky apps.

Then, in late 2021, [Shopify released Shopify Markets](https://www.shopify.com/news/global-by-default-shopify-markets-becomes-new-global-commerce-hub-for-merchants), a game-changing feature for brands looking to sell internationally. Markets allowed brands to sell to multiple countries from a single Shopify store while still controlling product catalogs, pricing, shipping, and other configurations on a per-country basis. Markets simplified international selling on Shopify dramatically and was acclaimed positively by both agencies and brands.

One year later, [Shopify released B2B](https://www.shopify.com/enterprise/blog/b2b-on-shopify), making it easier for brands to sell wholesale. Shopify B2B allowed merchants to manage company profiles, configure B2B-specific payment methods and terms, and set up dedicated price lists. It came at a time when more brands were looking at B2B to drive profitable growth and allowed brands to manage their wholesale operations from the same platform they knew and loved for DTC.

Until now, Markets and B2B have been entirely independent, each functioning according to different rules and concepts and configured in their respective UIs. Add to this Shopify POS, [which was launched in 2013](https://www.shopify.com/news/shopify-launches-revolutionary-point-of-sale-system) and also operated as a completely separate sales channel. Understandably, this created friction for merchants, who needed to navigate a complex maze of settings and rules to determine how their brand shows up in different channels.

![](https://cdn.sanity.io/images/kqgmf0g2/production/d624cc7cae90e895dd78cf1ee360266218b672ea-1280x720.jpg?fit=clip)

In the Summer ’24 Edition, Shopify announced that [Markets will become a unified home](https://www.shopify.com/editions/summer2024#markets) to manage all of your brand’s expansion efforts, whether you’re talking about new countries, B2B, or POS. For each channel, you can now configure the product catalog, availability, pricing, and much more from a single UI, and you can even combine different types of markets (e.g., all retail stores in the UK).

This not only gives brands an unprecedented amount of flexibility, but it also dramatically reduces the operational effort of maintaining multiple sales channels.

Finally, Shopify also announced that [each market will be able to use a separate business entity](https://www.shopify.com/editions/summer2024#multiple-business-entities) for payments. This long overdue change often prevented international brands from adopting Markets, forcing them to use expansion stores with all their quirks and limitations.

Our team was pretty excited about this change: It brings much-needed consistency to several areas of the platform and unlocks a range of use cases that were not possible before, such as having completely different themes for different markets or having complete control over the product catalog available to retail stores. It all _feels_ right, as evidenced by the ecosystem’s overwhelmingly positive response.

The new Markets experience is not available to the public yet, but you can [sign up](https://www.shopify.com/editions/summer2024#markets-top-10) to get notified when it will be released.


## New Shopify POS Functionality Gives Your Retail Stores Superpowers

Besides Markets, Shopify has put a lot of effort into making sure that all the different sales channels they offer to merchants are fully integrated. In the process, they’ve resolved some annoying gotchas and inconsistencies that had bothered merchants for years and unlocked new, exciting use cases.

POS got a lot of love in this regard. First of all, the POS hardware is now available in nine new countries–Belgium, Denmark, Germany, Ireland, Italy (yay!), the Netherlands, New Zealand, Spain, and the UK. In the last few years, we’ve seen pretty strong demand for Shopify’s POS devices in Europe, so it’s great to finally be able to offer them to merchants–Shopify’s hardware is excellent, and we can’t wait to experiment with it a bit more.

Secondly, Shopify is also enabling truly unified shopping experiences with two new features that bridge the gap between online and offline:

* [Ship to store](https://www.shopify.com/editions/summer2024#ship-to-store), which boosts Shopify’s existing BOPIS (Buy Online, Pickup In Store) functionality by allowing customers to choose their favorite pickup location regardless of inventory availability. When the product is unavailable, Shopify will seamlessly orchestrate delivery to the customer’s chosen pickup point.
* [Ship from store](https://www.shopify.com/editions/summer2024#ship-from-store), which allows merchants to use their stores as last-mile fulfillment networks. Online orders will appear on the retail store’s POS interface, from which store operators can fulfill the orders or, if unable, delegate fulfillment to another location or back to a standard fulfillment center.

![](https://cdn.sanity.io/images/kqgmf0g2/production/4b3bebec01781cec89054946a6bb6a758e528894-1280x720.jpg?fit=clip)

Finally, POS became more intelligent and more integrated with the rest of the Shopify ecosystem. This includes functionality such as:

* [One-tap digital receipts](https://www.shopify.com/editions/summer2024#digital-receipts-with-opt-ins), which can be delivered by email, text, or, if the customer has a Shop Pay account, to the Shop app.
* The ability to [collect personal information](https://www.shopify.com/editions/summer2024#require-info-at-checkout) such as name and email, marketing opt-ins, and sales staff attribution at checkout.
* Automatic integration with your store’s [return rules](https://www.shopify.com/editions/summer2024#return-rules), which reduces the likelihood of out-of-policy returns.

Combined, these features allow brands to make the most of their physical stores, reducing fulfillment costs, improving the customer experience, and helping brands collect more zero-party data. In an era when all merchants are trying to do more with less, this is the sort of innovation that we like to see from Shopify.

## Checkout Is Getting a Flexibility Boost 

Shopify’s checkout has long been a significant component of the platform’s value proposition and, at the same time, one of its biggest weaknesses. While it’s great for merchants to be able to delegate compliance concerns or checkout CRO to Shopify, the lack of customizability in the checkout flow has prevented specific categories of brands from implementing their ideal customer experience or, in some instances, from adopting Shopify altogether.

Some of this rigidity is by design: Shopify doesn’t want brands to shoot themselves in their metaphorical foot by making changes that could negatively impact their conversion rates. Finding the right balance between flexibility and compliance with industry regulations is also challenging, especially with the new limitations imposed by [PCI DSS v4](https://www.shopify.com/partners/blog/checkout-compliance).

That said, Shopify has been doing some great work on this front over the last few years by adopting a two-pronged approach: They’ve been opening up the checkout to more types of customizations and more elaborate use cases, but they’ve also been forcing merchants to use a set of standardized APIs (dubbed [Checkout Extensibility](https://www.shopify.com/enterprise/blog/checkout-extensibility-winter-editions)) to alter their checkout flow.

![](https://cdn.sanity.io/images/kqgmf0g2/production/bf8f13000bd1a4fc566adcfea2f55adb32bde12a-1280x720.jpg?fit=clip)

In the latest Edition, Shopify has continued on this path by releasing a slew of new features and customization APIs for their checkout:

* [Checkout Blocks](https://www.checkoutblocks.com/), a third-party app that allowed merchants to apply complex customizations to their checkout in a no-code UI, has been acquired by Shopify and is now free for all Shopify Plus merchants. It’s a fantastic product, and we couldn’t be happier for [Gil](https://www.linkedin.com/in/gilgreenberg/) and his team!
* Checkout will soon support [split shipping](https://www.shopify.com/editions/summer2024#split-shipping), allowing customers to see when an order will be split into multiple shipments and pick a different shipping method for each shipment. On a similar note, it’s now possible to [capture partial payments](https://www.shopify.com/editions/summer2024#payment-per-fulfillment) when part of an order is fulfilled.
* In a move that will undoubtedly be appreciated by brands outside the US, Shopify is now offering the ability to implement third-party integrations for [pickup points](https://www.shopify.com/editions/summer2024#3p-pickup-points-api) (not available yet) and [address autocompletion](https://shopify.dev/docs/api/checkout-ui-extensions/unstable/targets/utility/purchase-address-autocomplete-suggest), as well as to collect region-specific [address fields](https://www.shopify.com/editions/summer2024#region-specific-addresses) and different forms of [tax ID](https://www.shopify.com/editions/summer2024#tax-id-fields) for individual and business customers.
* Developers can now use the [Checkout Branding API](https://shopify.dev/docs/apps/build/checkout/styling) (available to Shopify Plus merchants only) to configure the checkout flow’s overall styling and UI elements. Additionally, they can [pre-fill the address at checkout](https://www.shopify.com/editions/summer2024#prefilled-addresses), which is handy for gift and wedding registries and other non-traditional shopping experiences.

These changes, most of which are targeted at international brands or brands with complex use cases such as marketplaces, give merchants some much-needed flexibility while still allowing Shopify to guarantee compliance and retain control over the end-user experience. 

In fact, we were working with a couple of brands waiting for some of this functionality to switch to Shopify, and we can’t wait to try it in the wild.

## Analytics, Controls, and Automation for Operators That Mean Business

Last but not least, Shopify announced a range of new features aimed at larger, more sophisticated brands that need greater visibility into and control over their businesses.

The spotlight goes to the [new Shopify Analytics](https://www.shopify.com/editions/summer2024#rebuilt-analytics), which allows merchants to build advanced custom reports and dashboards and, soon, query their data directly using ShopifyQL. Combined, these two features unlock much greater flexibility when it comes to business analytics, reducing the need for merchants to roll out and maintain dedicated business intelligence infrastructure.

![](https://cdn.sanity.io/images/kqgmf0g2/production/b489a739028c98fd8168cafd505dd0874b2b0c52-1280x720.jpg?fit=clip)

Organization settings and staff access also received some love. While the details are not completely fleshed out yet, it looks like companies will soon be able to [manage multiple stores from a unified interface and](https://www.shopify.com/editions/summer2024#organization-settings) assign staff access through a [Role-Based Access Control (RBAC) system.](https://www.shopify.com/editions/summer2024#role-based-access-control)

Finally, Shopify is releasing several improvements for Shopify Flow, their built-in task automation platform. Flow is becoming more powerful (thanks to features such as the ability to [send direct requests to the Admin API](https://www.shopify.com/editions/summer2024#send-admin-api-in-flow)), easier to use (see the [improved UX for working with metafields](https://www.shopify.com/editions/summer2024#custom-data-for-flow)), and more convenient to debug when something goes wrong (with a [better search experience](https://www.shopify.com/editions/summer2024#search-runs-for-flow) and [manual reruns](https://www.shopify.com/editions/summer2024#manual-reruns-in-flow)).

While Flow still leaves a lot to be desired (how much longer until we can use the result of an API call inside Flow?!), it’s a robust product for automatic basic tasks in a low-code environment. In fact, we’ve been able to use it in several instances where we would have previously reached for a custom app or an external automation platform, such as Zapier.

## Hydrogen Gets The First-Class Treatment: Visual Editor and B2B Storefronts

On the headless front, much work went into creating consistency between Hydrogen’s off-the-shelf capabilities and what brands can do with Online Store.

The most prominent announcement here was the new [Hydrogen Visual Editor](https://www.shopify.com/editions/summer2024#hydrogen-visual-editor), based on an open-source solution called Utopia. The editor, which is yet to be released, will allow marketers to manage the content of their storefronts through a visual page builder.

Furthermore, the new visual editor _actually updates the underlying code_ of your storefront rather than loading content through a client-side network call. This comes with several benefits, including much faster page load times and all the goodies of Git-based version control.

In the past, we’ve had to roll out similar features manually through solutions such as Sanity and Builder.io, so it’s great to have this out of the box and officially supported by Shopify. That said, we were surprised that Shopify didn’t just acquire an established player in the space, such as [Pack](https://packdigital.com/) or [Instant](https://instant.so/), and integrated their solution natively.

We’re also still waiting for the day when Shopify will decide to unify its content management solutions, using the same technology across Online Store and Hydrogen. Perhaps this is a small step in that direction.

![](https://cdn.sanity.io/images/kqgmf0g2/production/257a779594efae973c9a1d3fe3c5d84b98eb04e0-1280x720.jpg?fit=clip)

In addition to the Visual Editor, it is now possible to launch [headless B2B storefronts](https://shopify.dev/docs/storefronts/headless/bring-your-own-stack/b2b)–a feature that was previously only available for Online Store. There’s even a [Hydrogen B2B template](https://github.com/Shopify/hydrogen/tree/main/examples/b2b) that you can leverage to speed up time-to-market if you wish.

These are the major announcements, but Shopify also announced [many additional improvements to Hydrogen](https://hydrogen.shopify.dev/update/summer-editions-24-announcing-the-hydrogen-visual-editor-and-a-ton-of-dx-improvements), such as an optimistic cart API for instantaneous cart updates, official support for Vite, native integration with Shopify Analytics and the Customer Privacy API, better environment variable management, and improved SEO tooling.

One of the main problems with headless Shopify architectures has been the feature and capability gap between Hydrogen and Online Store. There are still inconsistencies to figure out, especially when it comes to the app ecosystem. Still, with some of these announcements, it feels like we’re getting closer, which is excellent news for all merchants that need a more sophisticated storefront than what Liquid themes allow.

## There’s Much More…

In this article, we have deliberately omitted a lot of stuff, cherry-picking the announcements and capabilities that were most relevant to the work we typically do with our clients. We didn’t talk about the [improvements to Shopify Magic](https://www.shopify.com/editions/summer2024#ai-for-commerce) or all the work Shopify is doing around [third-party sales channels and Shop](https://www.shopify.com/editions/summer2024#connect-with-customers), their own marketplace. If you run a Shopify brand, we encourage you to check out [the official Editions site](https://www.shopify.com/editions/summer2024#connect-with-customers) to ensure you’re not missing anything!

That said, it’s clear that Shopify plans to continue pushing in all directions. For smaller brands, they are rolling out features that allow them to do more with less, leveraging the strength of Shopify’s ecosystem and economies of scale.

For larger brands, they’re making the platform more flexible to support more complex use cases. At the same time, though, they’re also creating consistency and feature parity across different flavors and sales channels to minimize the amount of gotchas and “insider knowledge” required to navigate the Shopify universe.

Given the size of that ecosystem, it’s an uphill battle, but if anyone has the market traction and R&D budget to pull this off, it’s Shopify–and we’re excited to be part of the ride.

Shopify Summer ’24 Edition: Are Things Getting Serious?

If you have used Shopify before, you’ve probably fallen in love with the Theme Editor. With its flexible content management options and smooth editing experience, this little piece of functionality is one of the reasons why brands love Shopify so much, and among the aspecs that make the platform so user-friendly compared to its competitors.

But if you decide to go headless, you might be appalled to find that the Theme Editor is not available on Hydrogen. In this case, you will need to either manage your content through code–a solution that dramatically slows down the pace at which you can make content changes–or implement your own content management solution.

In this article, we’ll show you how to do just that: by using Sanity, one of the most renowned and established headless content management solutions available today, we’ll give you quick walkthrough of how you can create a visual content management experience for your headless Hydrogen store.

Let’s dive in!

## Creating Our Content Schema

First of all, let’s create a new Hydrogen application:

```
$ npm create @shopify/hydrogen@latest
```

Now, sign into [Sanity](https://www.sanity.io) and create a new project. When asked how you want to set up your project, pick “From scratch with CLI”:

![](https://cdn.sanity.io/images/kqgmf0g2/production/6e5f37b582d5a25e0f14746437677f4f367331d5-1999x1165.png?fit=clip)

Your project and a public production dataset will be created. You will also receive instructions on setting up Sanity Studio for a JavaScript codebase.

![](https://cdn.sanity.io/images/kqgmf0g2/production/2a13ec2cd76a56f54e53e28442d682c9e82fb222-1999x1371.png?fit=clip)

Now, run the Sanity Studio setup command within the Hydrogen codebase, and name the resulting folder `studio`:

```
$ npm create sanity@latest -- --project [YOUR PROJECT ID] --dataset production --template clean
```

This should be the end result:

![](https://cdn.sanity.io/images/kqgmf0g2/production/3f411a4035a00219d829c4ce4387d89184246170-626x684.png?fit=clip)

All the files generated for Sanity Studio

Next, let's create a new document in Sanity to display later in Hydrogen. How about a promotional banner? Open `studio/schemaTypes/index.ts` and create the `banner` type:

```
import {defineField, defineType} from 'sanity'

const banner = defineType({
  name: 'banner',
  title: 'Banner',
  type: 'document',
  fields: [
    defineField({
      name: 'title',
      title: 'Title',
      type: 'string',
    }),
    defineField({
      name: 'content',
      title: 'Content',
      type: 'text',
    }),
  ],
})

export const schemaTypes = [banner]
```

Now run Sanity Studio locally, open [http://localhost:3333/](http://localhost:3333/), and create a few banners:

```
$ cd studio && npm run dev
```

![](https://cdn.sanity.io/images/kqgmf0g2/production/5038e128559f997b3b660faa780ac95a05aa43f4-1999x1234.png?fit=clip)

Et voilà, our content is available in Sanity! Now, it’s time to connect Hydrogen to Sanity, so that we can actually retrieve and display the content.

## Connecting Hydrogen to Sanity

We now need to connect our Hydrogen store to Sanity to retrieve this data and display it on the homepage. Let's install the official integration package in the root folder:

```
$ npm i hydrogen-sanity
```

Add a couple of environment variables to `.env`:
```
SANITY_STUDIO_PROJECT_ID=[YOUR PROJECT ID]
SANITY_STUDIO_DATASET=[YOUR DATASET NAME, USUALLY "production"]
SANITY_STUDIO_URL="http://localhost:3333"
```

Update the `server.ts` file from the root to include the Sanity Loader:

```
// ...all other imports
// Add imports for Sanity Loader and Preview Session
import {createSanityLoader} from 'hydrogen-sanity'

// Inside the default export
export default () => {
  // ... Leave all other functions like the storefront client as-is

  // (Prerequisite) If not already initialized, create a `withCache` handler...
  const withCache = createWithCache({cache, waitUntil, request})

  // 1. Configure the Sanity Loader and preview mode
  const sanity = createSanityLoader({
    withCache,
    client: {
      projectId: env.SANITY_PROJECT_ID,
      dataset: env.SANITY_DATASET,
      apiVersion: env.SANITY_API_VERSION || '2023-03-30',
      useCdn: process.env.NODE_ENV === 'production',
    },
  });

  // 2. Make Sanity available to all action and loader contexts
  const handleRequest = createRequestHandler({
    // ...other settings
    getLoadContext: () => ({
      // ...other providers
      withCache,
      sanity,
    }),
  })
}
```

Your Sanity client will now be available in `context.sanity` in all your Remix loaders!

## Retrieving Content from Sanity

Let’s try to visualize the banners we have created previously. 

Inside the homepage `app/routes/_index.tsx`, add a Sanity query to the loader function:

```
export async function loader({context}: LoaderFunctionArgs) {
  // ...other storefront queries

  const banners = await context.sanity.loadQuery(`*[_type == "banner"]`);

  return json({
    // ... storefront queries
    banners,
  });
}
```

And inside the same file, modify the UI to display the data we’re retrieving:

```
export default function Homepage() {
  const {banners} = useLoaderData<typeof loader>();

  return (
    <div className="banner-container">
      {banners.data.map((banner) => (
        <div key={banner._id} className="banner">
          <h2>{banner.title}</h2>
          <p>{banner.content}</p>
        </div>
      ))}
    </div>
  );
}
```

And here you go! We’ve added a bit of CSS to make the preview look nicer:

![](https://cdn.sanity.io/images/kqgmf0g2/production/9b20bed734c392865e89a5ec55bf3c2bf569c1a3-1534x416.png?fit=clip)

Obviously, this is a very basic example–in the real world, you’ll have a much richer content schema. You may even allow your content editors to compose pages however they want by creating a 1:1 mapping between your Sanity schemas to React components, adding live previews, etc.

The sky’s the limit, and we encourage you to check out [the Sanity documentation](https://www.sanity.io/docs) to learn about all the possibilities!

## Keep Up with The Ecosystem

In this article, we have rolled our custom Hydrogen-Sanity integration, but the Remix and Hydrogen ecosystem are evolving rapidly. In fact, Sanity used to offer ready-made templates for integrating with Hydrogen, but they’ve since been archived. Shopify also just announced that they will be [releasing their own visual editor very soon](https://hydrogen.shopify.dev/update/summer-editions-24-announcing-the-hydrogen-visual-editor-and-a-ton-of-dx-improvements), in which case it might be worth switching over!

All of this to say, make sure to stay on top of what’s happening in the ecosystem and follow the latest best practices if you don’t want to be left behind. And if you _do_ deviate from those best practices, make sure that you always have a good reason for doing it!

How To Integrate Your Shopify Hydrogen Store with Sanity CMS

So, you’ve reached the hard conclusion that [you need to build some middleware](https://nebulab.com/blog/ecommerce-middleware) for your Shopify store—perhaps you need to integrate with an exotic third-party system that doesn't offer a native app, or you have a complex subscription flow that cannot be accommodated by an off-the-shelf solution.

But once you've mapped out all the business requirements, you're still left with a million decisions to make: where should you host your middleware? What's the best architecture, a monolith or microservices? Should your code run on a fixed cadence or respond to Shopify's webhooks?

In this article, we're publishing some broad technical considerations we've collected over the years while working on middleware implementations for our clients. We suggest treating these as general guidelines: your mileage may vary depending on your requirements, team composition, and growth stage.

Let's dive in!

## Reactive vs. Scheduled Middleware

The first crucial architectural decision you'll make is whether your middleware should be reactive or scheduled.

Reactive middleware responds immediately to events triggered by external actions, such as customer purchases or inventory updates. It's the preferred choice when dealing with time-sensitive business logic, such as sending email notifications or updating order information.

In reactive middleware, incorporating a queue mechanism is imperative to facilitate the asynchronous processing of incoming event payloads. By decoupling the reception of webhooks from the actual processing logic, queues create a buffer that allows your middleware to absorb workload spikes seamlessly. They also mitigate the risk of data loss during processing disruptions, ensuring that all incoming events are reliably processed.

Queues are de facto mandatory when building middleware for Shopify, as your store will deactivate your webhook subscription [in case of multiple failures/timeouts.](https://shopify.dev/docs/apps/webhooks/best-practices#respond-quickly)

Additionally, you should design reactive middleware to be idempotent and resilient against race conditions, e.g., when handling duplicate or out-of-order event notifications. This allows brands to mitigate the risk of data corruption.

Scheduled middleware, on the other hand, operates on a predefined cadence, executing tasks at regular intervals. It's the preferred choice when dealing with bulk data operations, such as subscription processing or (in some cases) integrations with third-party systems.

Because scheduled middleware might process a substantial amount of data during each execution, optimizing performance and resource utilization is essential. This can be achieved by grouping data into manageable chunks and processing it in batches, minimizing resource contention and maximizing throughput. When integrating with third-party systems, it's also essential to be mindful of rate limits, maximum payload sizes, and the opportunity to leverage batch APIs whenever available.

By understanding the distinct functionalities of reactive and scheduled middleware, businesses can leverage these tools strategically to orchestrate complex workflows and optimize their Shopify operations for efficiency and scalability.

## Monoliths vs. Service-Oriented Architectures

Especially in larger projects, it's tempting to implement your middleware logic as a constellation of microservices, making up what's typically called a Service-Oriented Architecture, or SOA for short. Technically, these services may run as traditional long-lived web applications, but we often see them deployed in serverless environments such as AWS Lambda or Cloudflare Workers.

The theory is that this design increases technical freedom and reduces maintenance overhead: for instance, the subscription processing engine may be implemented using a technology different from the WMS integration. Plus, if they're deployed as serverless functions, there's no need to worry about scaling the services to match transaction volume because the infrastructure provider will handle that responsibility for us.

In our experience, however, most SOA setups suffer from premature optimization. The additional freedom and scalability come at the expense of a more complicated development and infrastructure setup, with multiple codebases to maintain and constraints on the deployment process. Code reuse is also more complicated, and rather than going through the hassle of building and maintaining an internal SDK, engineering teams often end up duplicating the shared code. In other words, the additional effort and complexity often outweigh the gains.

Because of this, when faced with complex middleware architectures, we always consider whether there's a chance to simplify things by moving to a [Majestic Monolith](https://signalvnoise.com/svn3/the-majestic-monolith/) deployed as a traditional, long-lived Web application. While they're not as fancy as a serverless SOA, monoliths have several advantages:

* Engineers only need to work in one codebase to make orthogonal changes, which makes it easier to work atomically.
* Code sharing across API endpoints and scheduled jobs is trivial since everything's in the same application.
* We only need to write and maintain a single deployment pipeline, which makes deployments simpler and more robust.
* We eliminate the need to deal with network failures, data model inconsistencies, and data synchronization issues.
* It's still easier and cheaper to find and onboard new engineers on a monolith vs. a SOA.

This is not to say that microservices and serverless architectures are always bad. There are situations where they can help with scalability, e.g., for trivial middleware that only needs to respond to a specific webhook (in which case a serverless infrastructure is acceptable) or when a particular piece of business logic can be optimized by rewriting it in a more suitable technology. However, these pros always need to balance against the additional complexity introduced into the system.


## Keep Your Options Open

As we mentioned at the beginning of this article, your mileage may and will vary, especially as time passes and your middleware starts taking on more responsibilities. Our suggestion is to regularly re-evaluate your design and architectural choices to ensure that your current setup is still the ideal fit for your needs.

Furthermore, remember that the best middleware is no middleware. Whenever you see an opportunity to simplify your architecture by removing custom logic in favor of a third-party solution, you should seriously evaluate it. E-commerce brands are not tech startups, and every dollar you save in development costs is a dollar you'll be able to invest in other areas of the business.

If you are struggling with fine-tuning your custom integrations or business logic, [don’t hesitate to reach out](https://nebulab.com/contact-us): we can help you navigate and streamline the complexity, finding the ideal setup for your brand.

Designing and Scaling High-Throughput Shopify Middleware

On August 28, 2025, [Shopify will sunset the ability to customize your `checkout.liquid` template](https://shopify.dev/docs/themes/architecture/layouts/checkout-liquid).

Newly created stores on the Shopify platform will already notice that they cannot use this template to customize their payment steps, thank you, and order status pages. Shopify is reigning in control over these pages and forcing merchants to migrate to [Checkout Extensibility](https://www.shopify.com/plus/upgrading-to-checkout-extensibility?shpxid=169152ee-9333-4686-13FB-D40F49B3F520). [Recent articles](https://www.shopify.com/plus/customers/monos) published by Shopify promote Checkout Extensibility as the faster and more maintainable way to extend your store’s checkout experience.

Unfortunately, with limited control over the checkout, thank you, and order status pages, merchants have also lost the ability to place tracking pixels on these pages. To remedy this, Shopify has introduced [Web Pixels](https://shopify.dev/docs/apps/marketing/pixels). Web Pixels can be either standalone (Custom Pixels) or part of a Shopify App (App Pixels), and merchants can use them to track both predefined and custom analytics events.

In this article, we’ll examine the inner workings of App Pixel and Custom Pixels and discuss alternatives merchants can deploy when they need additional granularity in their data.


## App Pixels

App Pixels are part of Shopify Apps that you install: for example, the [TikTok app](https://apps.shopify.com/tiktok) provides an App Pixel out of the box–you just need to enable it from the Shopify Admin.

There are several benefits to using App Pixels over adding custom tracking code to your theme: the new structure simplifies the installation and removal of the pixel, allows you to comply with customer privacy regulations out of the box, and streamlines the integration of your tracking logic across different types of checkout (e.g., Shop Pay vs. one-page vs. three-page checkout).

While this new approach to tracking pixels is a significant step forward, not every platform has a Shopify App available; therefore, not every platform exposes an App Pixel. If your tracking platform does not have an App Pixel you can install, you might need to go with Custom Pixels.


## Custom Pixels

Custom Pixels can be used to integrate tracking platforms that do not expose an App Pixel or when you want to track a custom event or datapoint. Your pixel can subscribe to a [fixed set of events that Shopify publishes](https://shopify.dev/docs/api/web-pixels-api/standard-events) or to [custom events](https://shopify.dev/docs/api/web-pixels-api/emitting-data) published by your theme and send the information to an external service.

Similar to App Pixels, Custom Pixels can be enabled and disabled through the Shopify Admin, and they automatically conform to the customer’s privacy preferences, which makes them a powerful tracking solution fully integrated within Shopify.

With that said, Custom Pixels also have their limitations.

First of all, Custom Pixels [are sandboxed in iframes](https://shopify.dev/docs/apps/marketing/pixels#lax-sandbox-custom-web-pixel). Because of that, you might run into limitations with specific tracking scripts. We recommend working with your tracking platform to resolve these issues whenever possible.

Secondly, Custom Pixels only have access to a limited set of data. During a recent migration from custom checkout scripts to Web Pixels, we encountered a limitation on some Custom Pixels, specifically around conversion tracking. By default, Shopify publishes the `checkout_completed` event. As part of this event, Shopify [sends along limited order- and customer information](https://shopify.dev/docs/api/web-pixels-api/standard-events/checkout_completed). However, The tracking tags installed on our store used additional information, like the customer order count and type of purchase, that we originally included in the checkout script.

If you run into such limitations, there are a few alternatives you can try. That being said, each comes with trade-offs, and you should ensure the additional implementation and maintenance effort is worth it.


## Server-Side Tracking

Instead of relying only on Web Pixels, you can use server-side tracking to enrich (or replace) the data sent to your tracking platforms. Because this logic is not running in the browser, you can call the Admin API and access attributes that would otherwise not be available through the Storefront API.

This is a significant advantage, but it comes at a cost: you’ll have to manage custom code that runs on a separate server (or on a platform [such as Gadget](https://nebulab.com/blog/custom-shopify-automations)), and you will not be able to benefit from Shopify’s primitives for Web Pixels, putting the onus on you to deal with aspects such as privacy preference compliance.

An interesting middle ground is to use the [Shopify Flow](https://apps.shopify.com/flow) app. With the ability to [send HTTP requests](https://help.shopify.com/en/manual/shopify-flow/reference/actions/send-http-request) and the [new action to run custom JavaScript code](https://help.shopify.com/en/manual/shopify-flow/reference/actions/run-code), Flow gives you a robust set of tools to send information to an external API with attributes that your Web Pixels or frontend logic cannot easily access. You’ll still need to maintain the logic required for your solution, but Shopify will at least take care of hosting and executing it.


## Checkout Extensions

One of the benefits of the new Checkout Extensions system is that you can inject custom logic and UI into your checkout. Shopify allows extensions [to publish custom analytics events](https://shopify.dev/docs/api/checkout-ui-extensions/2024-01/apis/analytics) with any attributes you want. As Checkout Extensions have fewer restrictions than Custom Pixels, they can be used to pull extra information from the Storefront API and emit a custom analytics event. Your Custom Pixel can then send this event to any third-party tracking platform.

The implementation and maintenance cost here is relatively low: as long as your Checkout Extension adheres to the official APIs, this can be a reasonably robust solution. However, because Checkout Extensions can only access the Storefront API, you will have access to a more limited dataset than with server-side tracking.

You will also need to set up a custom Shopify app on your store and expose the extension to your theme. Luckily, Shopify makes this relatively easy by providing robust tooling and hosting the app directly, which means you don’t need external servers.


## Session Storage

Finally, another approach is to use the browser’s Session Storage to temporarily store attributes as the customer browses your store. You can then retrieve these attributes from your Custom Pixel at checkout. 

For example, you could use Session Storage to store a referrer URL here or the type of order the customer is completing (OTP vs. Subscription) _before_ checkout starts. Custom Pixels have access to Session Storage, which means they can read these attributes when the `checkout_completed` event is fired and forward them to your tracking platform.

Using Session Storage is the simplest way to add additional context to any analytics event: there is no need to set up a custom Shopify app, as all the logic can live in your theme and Custom Pixel. Additionally, in contrast to Checkout Extension, it not only allows you to include additional data that you read from Shopify’s API but also to collect behavioral data while the customer is browsing your store.


## Balancing Data Enrichment with Maintenance Effort

Web Pixels are a robust tracking solution fully integrated within Shopify’s ecosystem.

With more platforms getting on board, App Pixels are quickly becoming a straightforward and reliable solution for installing tracking pixels. In addition, Shopify enforces that the customer has opted into data collection before enabling these pixels, which is a step that is often overlooked when implementing tracking tags on a storefront.

Custom Pixels have some rough edges: their sandbox allows Shopify to enforce similar privacy constraints as for App Pixels but also creates situations where tracking tags don’t work, leaving merchants at the mercy of the tracking platform to build an App Pixel or to update their tracking script.

Finally, when neither App Pixels nor Custom Pixels provide the right data, you can consider alternatives such as Server-Side Tracking, Checkout Extensions, or Session Storage.

We work closely with business stakeholders to determine what events and data we need to track and how the data will be used. We then use that information to build a solution that will satisfy the brand’s needs while also minimizing the technical maintenance burden.

If you are migrating to Checkout Extensibility or need assistance with your existing tracking setup, [don’t hesitate to reach out!](https://nebulab.com/contact-us)

Web Pixels on Steroids: How To Enrich Your Shopify Analytics

In the complex world of e-commerce technology, Shopify stands out as a beacon for businesses eager to establish or expand their online presence. Its user-friendly interface, coupled with a vast ecosystem of apps and integrations, has made it the go-to platform for merchants. Still, the convenience offered in the off-the-shelf package is not enough for everyone.

While Shopify's app store provides many easy-to-install solutions that promise quick wins, the reality is that the more complex your business needs, the less likely you'll find an app that fits the requirements. And, as businesses grow and operations become more complex, the limitations of a simple Shopify build become more and more apparent until they bring businesses to a crossroads: either simplify operations to fit into Shopify’s boundaries, or heavily customize Shopify to play by their rules.

The former path might be acceptable and sometimes even advisable for smaller stores. Building complex Shopify customizations requires significant resources and can be a source of [technical debt](https://nebulab.com/blog/shopify-technical-debt); as such, these projects should always be justified by a clear and compelling ROI.

But for brands in the upper midmarket/enterprise segment, building more complex automations and customizations on top of Shopify often makes perfect sense: these companies have complex internal workflows, custom tooling, and nuanced policies, and their e-commerce platform must learn to adapt and play nice with the existing ecosystem.

Luckily, Shopify’s ecosystem comes with rich tooling designed to create custom apps and integrations. In this post, we'll delve into some of these tools. More specifically, we’ll cover Shopify Flow, Zapier, e-commerce iPaaS Solutions, Gadget, and Greenfield Apps, exploring their pros and cons, ideal use cases, and some examples of the customizations they enable.


## Shopify Flow

[Shopify Flow](https://help.shopify.com/manual/shopify-flow) is a tool built into Shopify that allows creating automations without leaving the platform. It's a basic yet powerful way to respond to events generated within your online store (e.g., a new order being placed) with a set of actions (e.g., sending an email to your staff).

**Pros:**

* **Seamless Integration:** It’s designed specifically for Shopify, ensuring a smooth integration with your store. It’s Included in Shopify for free; no need to pay for extra software.
* **User Friendliness:** Shopify Flow comes with a visual workflow builder that requires no coding, making it accessible to non-technical users.
* **Third-Party App Support:** Shopify apps can extend Shopify Flow by adding their own triggers and actions, which expand the possibilities of the tool. This functionality is only available to Shopify Plus merchants.

**Cons:**

* **Complexity Limitations:** While powerful, Shopify Flow does not always cater to highly intricate integration needs that require custom coding.
* **Partial Support for External API Calls:** You can create an action that performs an API request to an external service (if you’re on the Shopify, Advanced, or Plus plan), but you cannot use the data you receive in any way. Shopify has committed to solving this in 2024.
* **Partial Support for External Emails:** At the moment, it's not possible to send emails using Shopify Flow, except for emails to staff members or as part of email marketing automations. You cannot send transactional emails to your customers or anyone else.

**Ideal Use Case:** Shopify Flow is your go-to for automating operational tasks within Shopify's ecosystem, particularly if you're a Shopify Plus user and can use all of the functionality it offers. It's ideal for businesses looking to streamline processes like tagging high-value customers for exclusive offers or automating restock notifications.

**Example Customization:** Automating the tagging of VIP customers based on their spending history and automatically enrolling them in an exclusive loyalty program.

## Zapier

[Zapier](https://zapier.com/) can be a good alternative to Shopify Flow, if you find its limitations unbearable. Via the Zapier app for Shopify, you can connect Zapier to your Shopify store and pick from an extensive list of triggers and actions to build your automation.

**Pros:**

* **Wide Range of Integrations:** Zapier can connect Shopify with over 3,000 web services, facilitating many different kinds of automations.
* **No Coding Required:** Zapier’s interface is similar to Shopify Flow, but offers even more power by allowing you to build more complex, more robust automations.
* **Rapid Deployment:** You can quickly set up new integrations and automations without the time and cost associated with custom software development.

**Cons:**

* **Pricing:** Zapier’s costs can quickly escalate as you increase your usage of the platform and build more complex workflows.
* **Dependent on Third-Party Connectors:** Even though it boasts more integrations than Shopify Flow, Zapier still relies on the availability and limitations of third-party connectors.

**Ideal Use Case:** Zapier is best suited for businesses that find Shopify Flow too limiting, but still need to build automations or integrate Shopify with other platforms quickly and without custom development.

**Example Customization:** Automatically adding new Shopify orders to a Google Sheets spreadsheet for advanced reporting and analysis.


## E-Commerce iPaaS

Integration Platform as a Service (iPaaS) solutions connect your online store with a variety of other systems, such as ERP, POS, and warehouse management systems (WMS), facilitating the automation of business processes across platforms. There are plenty of iPaaS solutions that integrate with Shopify–our favorite are [Patchworks](https://www.wearepatchworks.com/), [VL OMNI](https://vlomni.com/), [High Cohesion](https://highcohesion.com/), and [Pipe17](https://pipe17.com/).

**Pros:**

* **Connector Ecosystem**: Unlike Zapier, which is a generic automation platform, e-commerce iPaaS platforms specialize in connecting e-commerce platforms like Shopify with CRM, ERP, POS, and WMS systems.
* **Data Integrity:** E-commerce iPaaS platforms were designed to ensure data consistency across platforms, reducing synchronization errors and improving operational efficiency.
* **Bespoke Support:** with most iPaaS platforms, you can typically engage their customer support or professional services team to build connectors that are not already available.

**Cons:**

* **Integration Complexity:** Setting up more sophisticated connectors and automations may require technical expertise to configure and manage.
* **Cost:** The investment required to use an iPaaS reflects its enterprise-level capabilities, making it more suitable for larger businesses with complex needs. Most platforms will charge you per connection or event (e.g., a new product being created).

**Ideal Use Case:** E-commerce iPaaS solutions are ideal for medium-to-large businesses that require robust, real-time integrations between Shopify and other enterprise systems.

**Example Customization:** Integrating Shopify with an ERP system to automate order management, inventory management, and financial reporting, streamlining operations and reducing manual errors.

## Gadget

[Gadget](https://gadget.dev/) is a powerful full-stack serverless platform that allows building and hosting custom Shopify Apps, skipping all the repetitive tasks and accelerating the development cycle of your custom app. Through Gadget, you can accomplish all the automations and integrations that are not possible with off-the-shelf apps and integrators.

**Pros:**

* **Rapid Development:** Gadget offers a rapid development environment for Shopify apps, reducing time to market and human error.
* **Scalability:** Gadget is built to handle high volumes of data and traffic, making it suitable for growing businesses.
* **Developer-Friendly:** Gadget provides advanced tools and resources tailored for developers who need to create sophisticated apps, like Shopify API version management and pre-built React frontends that are compatible with Shopify’s security policies.

**Cons:**

* **Learning Curve:** Developing with Gadget requires a significant amount of technical knowledge, making it hard to access for non-developers.
* **Cost:** Custom apps may involve higher initial development costs compared to simpler integration approaches.
* **Single Environment:** As of today, multi-environment applications (staging+production, for example) are not supported. However, Gadget claims the feature will be released soon.

**Ideal Use Case**: Gadget is a powerful choice for tech-savvy teams looking to build a private Shopify app for their brand as quickly as possible.

**Example Customization:** Creating a custom loyalty program that’s not supported by any off-the-shelf loyalty apps for Shopify.


## Greenfield Apps

When none of the tools above is capable of fulfilling our complex business requirements, we are left with one extra solution, probably the most flexible one: building a custom Shopify app completely from scratch. We call these “Greenfield Apps.”

Greenfield Apps can extend the functionality of your Shopify store in whatever way you want, as long as your desired workflow is supported by Shopify’s APIs.

**Pros:**

* **Malleability:** Greenfield apps can be designed to meet your exact business requirements, offering unparalleled flexibility.
* **Direct Integration:** You can use greenfield apps to interact with all of Shopify's APIs, enriching your online store with custom business logic, Storefront and Admin UI components, and complex automation and integration workflows.
* **Technical Scalability:** Greenfield apps can grow with your business, accommodating new features and processes as needed, without financial or technological lock-ins.

**Cons:**

* **Development Cost**: Custom development is typically more expensive and time-consuming than pre-existing solutions.
* **Maintenance Effort:** Greenfield apps require ongoing maintenance and updates to ensure compatibility with Shopify's evolving ecosystem. \

**Ideal Use Case:** When your business requires unique functionality that cannot be addressed with existing apps or tools, greenfield Shopify apps provide a solution tailored specifically to your needs.

**Example Customization:** A bespoke app that provides a UI for a marketplace’s vendors to update product prices and availability, and instantly propagates those updates across multiple warehouses within your Shopify storefront.

## Complexity Is Not Always a Bad Thing

While Shopify's app ecosystem offers a solid foundation for run-of-the-mill retailers, expanding beyond these boundaries unlocks new levels of operational efficiency, customization, and customer satisfaction.

When considering your options for customizing your e-commerce store, remember that the right choice depends on your needs, budget, and technical capabilities. Make sure that you’re factoring in all of these elements before committing to a specific solution.

Building custom features and integrations may seem daunting, and might require resources and expertise that you don’t have in-house. But at the end of the day, this growing complexity is often a testament to your brand’s growth and the need to evolve your customer experience.

If you need help launching a custom feature or integration for your Shopify store, [feel free to reach out!](https://nebulab.com/contact-us) Our engineering team would love to help you figure out the right solution.


Building Custom Shopify Automations, From Beginner to Pro

Have you ever struggled with a simple addition to your Shopify store turning into a nightmarish project, full of intricacies and edge cases? Or maybe you’ve experienced the impatience of looking at your product page take forever to load, longing for the good old days when it showed up instantaneously? Or perhaps you’ve run into weird UI bugs caused by two of your apps not playing nice with each other?

When you launch a new Shopify store, everything’s fantastic: the theme is beautiful, the pages load fast, and the apps you’ve picked are a joy to work with. It feels like you’ve got everything figured out, and no one and nothing will ever change that.

But after a while, some friction shows up. Implementing new features takes longer. Bugs pop up. Site speed decreases, as does your conversion rate.

Your team (or your agency) now spends more time hunting down the things that are not working than implementing new functionality that could move the needle. But even though everyone’s dissatisfied with the state of things and your business is suffering, no one can pinpoint the root cause or figure out a definitive solution.

Starting from scratch looks like the only option, so that’s what you do. You change agencies, rewrite your theme, and call it a day. Unfortunately, the rewrite only helps temporarily: give them enough time, and things will revert to their original state, and the cycle will start all over again.

Sounds scary, doesn’t it? And yet it’s a story that we’ve heard from many Shopify merchants, disenchanted with their agency, internal team, or the Shopify ecosystem as a whole.

The good news is that it doesn’t have to be like this. There’s a way to keep your ecommerce store from degrading over time; all it requires is a more thoughtful approach to store development. In this blog post, we’ll outline what that approach looks like, and how you can adopt it.

But before we do that, we need to introduce the concept of technical debt.

## What Is Technical Debt?

Technical debt, often called just “tech debt,” refers to the compromises made in a system for short-term gains, which may lead to more complex maintenance and updates in the long run. It is the practice of taking shortcuts: installing unvetted apps for the sake of shipping a feature, implementing untested JavaScript “hacks” in your theme, breaking best practices for theme maintenance, or failing to keep up with the latest Shopify API updates.

These solutions help you move faster and will not kill your store in the short term, which makes them so appealing in the first place. But in the long term, the consequences will show up in the form of bugs, lower site speed, a slowdown in development velocity, and, in extreme scenarios, a decrease in conversion rate.

Unfortunately, Shopify’s marketing can be misleading when it comes to technical debt: the promise is that, by using Shopify, merchants will never need to worry about technology, and by extension, they will never need to worry about technical debt.

That is only partially true: while Shopify handles a lot of responsibilities for merchants, a merchant’s theme and app stack is still for the merchant to maintain, and it can accumulate technical debt just like any other software. Your theme can either be a beautifully architected piece of technology, highly performant and easy to evolve, or a hot mess of obscure hacks and patches no one understands anymore. You, the merchant, are ultimately responsible for deciding where you want this pendulum to swing.

But in practice, what are the sources of technical debt in Shopify that cause stores to lean one way or the other? Here’s a non-exhaustive list, but keep in mind that there are additional factors that are often unique to each store:

* **Multiple stores:** even after the advent of Markets and B2B in Shopify, many merchants keep using multi-store setups when they are not needed. Because each store is independent and stores can diverge from each other, this setup can be a significant source of technical debt, increasing the cost and complexity of making changes.
* **Too many apps:** Shopify’s blessing–its app ecosystem–is often its curse. When we audit Shopify stores, we are often shocked by how many apps the average store has installed. Often, not even the merchant can explain what all the apps do. This is the #1 source of bugs, compatibility issues, and a steep increase in license fees.
* **Too much JavaScript:** some custom themes present a large amount of JavaScript code, often using external libraries such as React, Angular, or jQuery. This complexity, which is sometimes uncalled for, makes it harder for developers to find their way around a theme, slows down your website, and introduces bugs.
* **Large Liquid files**: similar to the point above, Liquid files that are hundreds of lines of code quickly become hard for developers to understand and change, to the point where they might be deemed completely unmaintainable.
* **Outdated code:** if your store is not leveraging metaobjects or not using the full potential of Online Store 2.0, you might end up with weird hacks and workarounds to implement functionality that is now natively available in Shopify. Apps can compound this problem because they are sometimes slow to adopt new Shopify APIs and capabilities, reducing the flexibility and optionality of their user base.

There are additional factors that are not technical debt _per se_ but often lead to technical debt over time: examples of these would be the lack of a defined QA process for theme changes, which increases the likelihood of bugs, or the lack of theme documentation, which makes it harder for unfamiliar developers to find their way around the project.

## A Three-Step Approach to Managing Shopify Technical Debt

Managing technical debt in a Shopify store can be tricky for inexperienced merchants and developers. However, a structured approach can go a long way in effectively controlling it. Here’s the three-step process we typically adopt when we work with a merchant.

### 1. Measure the Business Impact

Before tackling technical debt, it's essential to understand the extent of the problem.

In traditional software projects, there are tools that attempt to measure the health of your code. These tools typically ingest your entire codebase and produce a “quality” score that tells you the overall state of the software and what areas you should improve.

The bad news is that most of these tools don’t work with Shopify themes because they’re structured differently than most other software. The good news is that, in our experience, such tools are ineffective: technical debt only matters insofar as it _actually_ impacts your business. Code quality, as measured by a machine, is rarely a good proxy for business impact.

Instead, you want to measure the effects of technical debt on your store’s real-world performance. There’s no one-size-fits-all metric here, but here are some that we’ve used:

* **Defect rate,** which measures the number of features your team has shipped that introduced one or more bugs in the customer experience.
* **Cycle time,** which measures the time it takes for your team to implement a change after that change has been prioritized.
* **Site speed,** which should be pretty self-explanatory.

Both defect rate and cycle time can be measured with a good project management tool, while site speed is typically measured with tools such as PageSpeed Insights.

With all these metrics, what matters most is not their absolute value but their directional trend over time: if they’re getting better and not worse, you’re moving in the right direction and can double down on your current approach.

### 2. Establish a Solid Foundation

Once you have a good grasp of the extent of the problem, the next step is to ensure there are no obvious sources of technical debt in your Shopify setup.

These are the aspects we typically focus on:

* **Leverage native Shopify features**: by using native functionality as much as possible, you are reducing the need for ongoing maintenance. Whenever you diverge from the built-in functionality, you should always consider the balance between innovation and the additional complexity you’re introducing into your store.
* **Minimize third-party apps**: in addition to increasing your license fees, each app you install into your store introduces more complexity, potentially slows the website, and can lead to bugs in the customer experience. Vet all the apps you install and ensure they are needed.
* **Adopt a version control system (VCS):** a VCS makes it much easier to document the changes developers are making to your theme, and to roll back to a previous version of the theme in case a bug pops up. From a technical standpoint, there’s no reason not to have a VCS in place for your Shopify theme.
* **Set up a test store:** a staging environment (sometimes called a “test store”) allows you and your ecommerce development team to test your changes safely before rolling them out to your customers. The caveat is that you will likely need to install all your apps in the staging environment, increasing your license fees.

While this is just the beginning, it will give your team an initial foundation they can build upon.

### 3. Prevent and Reduce Debt Over Time

With the basics in place, you can now adopt team-wide policies to help your team minimize the technical debt you introduce over time.

These are some of the policies that we adopt:

* **Call technical debt by its name:** if you only do one thing outlined in this article, it should be this. The #1 reason technical debt keeps growing is that developers do not have the technical understanding or psychological safety to talk about it. Ensure everyone is familiar with technical debt and comfortable calling out when a corner has been cut. A recurring team retrospective can be very helpful here.
* **Perform technical code reviews:** encourage developers to review each other’s code whenever a change is introduced. This means that developers will need to schedule time for code reviews, and your development velocity will slow down a bit, but the quality of the end product will benefit tremendously.
* **Establish a structured QA process**: ideally, QA should be done on every new change by your development team, who should be familiar enough with your store to understand whether a feature meets all the acceptance criteria. If that’s not possible, you can also designate the person in charge of website development.
* **Set time aside for tackling technical debt:** in the past, Shopify shared their internal strategy for dealing with technical debt, the [25 Percent Rule](https://shopify.engineering/technical-debt-25-percent-rule). It might not work for everyone, but having a clear understanding of how much time is acceptable to dedicate to refactoring technical debt will create a safe space for developers to work on it.

Some of these policies might be overkill for small stores, while others must be adapted to your needs. Ultimately, it all boils down to how much technical debt impacts your store and how many resources you can dedicate to fighting it.

## Technical Debt Is a Tool: Learn to Use It!

With this entire article focusing on eliminating and preventing technical debt in your Shopify store, you might be tempted to think that technical debt is something to be avoided at all costs. The reality is a bit more nuanced.

Like financial debt, technical debt is a tool: cutting corners helps you move faster at critical times of your business, such as before a big launch or public holiday.

And _just like_ financial debt, technical debt must also be paid off at some point. If you ignore it, its adverse effects will compound over time, severely impacting team morale and dragging down business performance.

Leveraging technical debt thoughtfully and intentionally is critical to a merchant’s success in the Shopify ecosystem. Doing it well requires a collaborative effort, with clear team agreements and robust processes tailored to your growth stage and team composition.

If you’re struggling with managing technical debt in your Shopify store, [reach out!](https://nebulab.com/contact-us) As a Shopify partner, have worked with some of the largest brands in the ecosystem and can help find the best solution for your store.


How To Manage Technical Debt in Your Shopify Store

For a long time, Shopify has been considered as the eCommerce platform for SMBs: easy to set up and maintain, with the largest ecosystem of integrations and service providers in the industry, the original promise of Shopify was to [arm the rebels](https://shopifyrebellion.gg/), giving every entrepreneur everything they need to launch an online store. This value proposition attracted millions of small businesses to the platform.

Historically, the downside of Shopify’s ease of use has been its lack of flexibility: Shopify has always been a featured-packed but ultimately closed platform, unable to offer the technical sophistication of competitors catering to the enterprise eCommerce space, such as [Salesforce Commerce Cloud](https://www.salesforce.com/products/commerce/) and [commercetools](https://commercetools.com/). Enterprise requirements demand a much more open and extensible architecture, which was at odds with Shopify’s promise of power and simplicity.

But in the last couple of years, Shopify has used its traction to push hard upmarket, with products such as [Hydrogen](https://nebulab.com/blog/shopify-hydrogen) and [Commerce Components](https://www.shopify.com/commerce-components) that are meant to appease the needs of the enterprise segment. The result is two-fold:

* Shopify has been eating into the market of its enterprise competitors. For enterprise brands, Shopify is a compelling product with incredible traction.
* SMBs have been taking an interest in more advanced architectures, such as headless and composable commerce, that Shopify did not offer before.

The fact that Shopify offers three different architectures, their original Online Store product plus Hydrogen and Commerce Components, and two commercial offerings, Shopify and Shopify Plus, often leaves operators confused and prone to analysis paralysis. In the worst-case scenario, we see brands make the wrong choice, leading to a more complex and fragile architecture than they were prepared for.

In this article, we want to provide a map for anyone looking to navigate Shopify’s different offerings and flavors so that you can make the right decision for your brand and maximize the return on your investment.

Let’s dive in!

## Online Store: Small but Mighty

Let’s start with the most basic and popular option: Online Store.

In technical terms, Online Store is Shopify’s monolithic commerce product, meaning that your e-commerce platform and storefront are bundled in the same package. When you go with Online Store, you can customize your store in two ways: by editing your theme (either through Liquid templates or the Theme Editor) or by installing apps from Shopify’s App Store.

In other words, when you use Online Store, Shopify controls and delivers your entire commerce experience end-to-end. This creates a streamlined experience for you and your Shopify developers: the Theme Editor will allow you to make most content changes yourself. Certain Shopify themes will even auto-update to the latest version–as long as you haven’t modified them too heavily–so you won’t need to use developer hours for theme updates.

![](https://cdn.sanity.io/images/kqgmf0g2/production/05cb8d62586c75912162aeed16bccd3b447caef5-1600x1052.jpg?fit=clip)

The most significant advantage of using Online Store, however, is the size of the ecosystem you will be able to access: pretty much every Shopify App has been built with Online Store in mind, which makes it incredibly simple to add new functionality to your store with a click of a button. The same goes for agencies and system integrators: most developers in the Shopify ecosystem are used to working with Online Store architectures, so it will be much easier to find someone to help you.

What’s the catch, then?

Well, as we mentioned in the introduction, larger brands have scoffed at this flavor of Shopify because it lacks flexibility and technical sophistication. As your store grows, you might start bumping into certain limitations that make it hard to keep a high quality bar: apps that don’t play nice with each other, performance issues that cannot be easily mitigated, and new features that cannot be implemented without unreliable workarounds.

To be fair, some of these issues are not caused by Online Store per se, but rather by an inexperienced development or marketing team that abuses the plug-and-play nature of this architecture and ends up shooting themselves in the feet.

However, it’s undeniable that Online Store offers less control to Shopify merchants than the alternatives, so let’s look at what else Shopify has to offer!

## Hydrogen: Let’s Lose Our Heads

[Hydrogen](https://nebulab.com/blog/shopify-hydrogen) is Shopify’s headless ecommerce product, and it was their first answer to more complex customization needs. Released in late 2021, the Hydrogen framework gives brands complete control over their shopping experience, allowing them to build custom frontends with literally no limitations.

In practice, the way Hydrogen works is that, rather than building a theme, which you then upload to Shopify, you create your Hydrogen storefront as a completely standalone JavaScript/React application that leverages a set of pre-built components provided by Shopify. This custom storefront will still use Shopify’s Storefront API to power most of its functionality, but because you control the entire codebase, you can easily implement custom functionality that Shopify’s backend doesn’t support and create richer customer experiences.

You can deploy Hydrogen apps on [Shopify Oxygen](https://shopify.dev/docs/custom-storefronts/oxygen), Shopify’s free hosting solution, or any other hosting platform that supports JavaScript, such as [Vercel](https://vercel.com/).

As we’ve already mentioned, the main upside of Shopify Hydrogen is control: with a headless store, the sky is quite literally the limit, and whether you can accomplish something mostly depends on how many resources you want to invest into the project. This flexibility allows brands to really push the boundaries of digital commerce and offer lightning-fast, highly engaging user experiences. By giving you more granular control, headless storefronts also make it easier to fine-tune your site’s speed and customize your integrations.

On the other hand, this level of control is not for everyone: if you want to go with Hydrogen, you need to ensure your development team has experience with headless solutions. Otherwise, you’re bound to create more problems than you’re solving. You can also expect the development and maintenance of your Shopify store to become a bit more complicated as you lose access to some of Online Store’s let-me-do-that-for-you functionality.

![](https://cdn.sanity.io/images/kqgmf0g2/production/a6338ec311c8c4db7308b78bed520d05dd67fbc0-1600x1052.jpg?fit=clip)

The other significant downside of going with Hydrogen is losing access to a big part of Shopify’s ecosystem: as we’ve mentioned earlier, most Shopify apps, and even many of Shopify’s internal features, have been built for Online Store shops. Hydrogen stores can forget about the Theme Editor and one-click app installations; instead, you will need to pick content management and other technology providers that offer an API, and then [implement and maintain those integrations yourself.](https://hydrogen.shopify.dev/integrations)

But what if not even headless commerce cuts it, perhaps because you have an existing eCommerce infrastructure that you want to migrate to Shopify more gradually, or because eCommerce is just one part of a much larger retail setup? 

Those are the kinds of problems that Commerce Components was built to solve.

## Commerce Components: The Composable Way

[Commerce Components](https://www.shopify.com/commerce-components) is Shopify’s answer to the rise in popularity of composable commerce, especially among enterprise merchants.

On the surface, composable architectures are not dissimilar from headless architectures: rather than having everything in one place, your Shopify storefront is implemented and hosted separately from your eCommerce stack and interacts with it through APIs. _Unlike_ in a headless architecture, however, you’re not just integrating with one service provider, but stitching together a plethora of them by picking the best-in-class provider in each category.

Let’s look at a practical example: the first component Shopify is making available as a standalone offering is Shop Pay, their accelerated checkout. That means you can use Shop Pay as your checkout even if you don’t use Shopify for Product Information Management (PIM) or as your Order Management System (OMS).

![](https://cdn.sanity.io/images/kqgmf0g2/production/0ae4e563810428092df43dce23463b6af5070fc2-1600x1052.jpg?fit=clip)

For large merchants, this is a very compelling proposal: it’s much easier to integrate smaller pieces of Shopify as needed rather than uprooting their entire tech stack. For Shopify, it’s a powerful way to get a foot in the door and eventually win more of a merchant’s business–as they’ve reiterated repeatedly in their recent earnings calls.

It’s crucial to note Shopify is very new to the composable space, and it will most likely take a while before Commerce Components becomes a first-class citizen in their ecosystem. Right now, it’s being used by some very large retailers, such as [Glossier](https://www.glossier.com/), but Commerce Components is a recent offering, and there’s still not much information about it. All Commerce Components deals need to go through Shopify’s sales team and are being discussed on a case-by-case basis–you can’t just sign up on your own and start building.

As cool as it may sound, the complexity of a composable architecture is not for the faint of heart. Think headless development, but times ten, because now you need to stitch together even more pieces. This architecture typically requires a dedicated engineering team, and it’s most often adopted by brands that treat technology as a first-class citizen: if you don’t have a CIO, CTO, or VP of Technology, Commerce Components is _almost certainly_ not for you.

If, on the other hand, you’re an enterprise brand running on a legacy infrastructure that you’d like to modernize, Commerce Components allows you to do so progressively and without dramatically disrupting your existing workflows or technology.

## So, Which One Should You Use?

If you still have doubts at this point, here’s a quick cheatsheet to understand what Shopify version to go with depending on your ecommerce store’s maturity:

* If you’re below $100M in annual GMV, just stick with Online Store. The simplicity of having everything in one unified package and the power of Shopify’s ecosystem will more than compensate for the lack of flexibility.
* If you’re beyond $100M in annual GMV and constantly running into technical limitations with Online Store, you might want to start evaluating Hydrogen. However, make sure to pick a partner that can support you and will not be scared by digging into the more technical aspects of running your store.
* If you’re a large/enterprise ($300-400M+ in annual GMV) retailer with a complex infrastructure and an established engineering discipline and want to either migrate to Shopify or integrate specific pieces of Shopify’s offering, Commerce Components might be a good fit.

With that said, keep in mind that these recommendations are a floor, not a ceiling: we have worked with small/medium brands that were ambitious and technical-savvy enough to go with Hydrogen well below the $100M/year threshold, and we’ve worked with brands doing $300M/year through Online Store. Any choice you make should be made in the context of _your_ business needs and capabilities–that’s where picking a strong technical partner with a broad understanding of these offerings can have a considerable impact.

If you need any help making a decision, we’d love to help! Our team has extensive experience working with brands from pre-revenue to $500M/year, and can advise on the best technical architecture for your brand. [Feel free to reach out!](https://nebulab.com/contact-us)


Comparing Shopify’s Online Store, Hydrogen, and Commerce Components

If you have been working with Shopify’s Hydrogen framework for some time, you might still have some scars after the
[migration from Hydrogen v1 to Hydrogen v2](https://nebulab.com/blog/shopify-hydrogen-v2-updates).

One of the major changes in Hydrogen v2 was the transition from a custom-built React framework to
[Remix](https://remix.run/), a relatively new framework that is seeing a lot of traction thanks to its streamlined
developer experience, its reliance on Server-Side Rendering and its deep focus on web standards.

Remix was a significant improvement over Shopify’s in-house React framework, and allowed Hydrogen stores to benefit
from a much larger ecosystem of Remix docs, plugins and system integrators. We’ve discussed the benefits at length in
[our blog post covering the migration](https://nebulab.com/blog/shopify-hydrogen-v2-updates).

Unfortunately, the migration process from Hydrogen v1 to Hydrogen v2 was also incredibly complex. So much so, that many
large brands were better off re-building their storefront from scratch with Hydrogen v2 rather than attempting to port
their existing codebase. This caused a lot of discontent and frustration with Shopify’s decision, which didn’t seem to
fully appreciate the complexity of maintaining a complex headless architecture.

Now, it _feels_ like history might be repeating itself: Remix just announced a new major release. Remix v2 comes with
several new features and improvements to the developer experience that Hydrogen developers will also benefit from.
However, Hydrogen teams are also worried that the transition to Remix v2 might be their latest time-suck and source of
frustration.

But is that really the case, or are things better this time around?

In the past few weeks, we’ve been following the Remix community and trying to unpack the implications of this release
for Hydrogen. Let’s see what this release actually means for you, and how you can make the best of it!

## What’s New in Remix v2 for Hydrogen Devs?

Let’s start by taking a look at the changes and new features in Remix v2 that are most relevant for Hydrogen developers.

Keep in mind that you can always read the [release announcement](https://github.com/remix-run/remix/releases/tag/remix%402.0.0)
if you want to see the complete list of changes!

### New Dev Server with HMR and HDR

If you’ve used a more established React framework such as Next.js, you’re probably familiar with HMR even though you
might not know the acronym. HMR, which stands for Hot Module Replacement, is the feature that allows the page to update
instantaneously and reflect any changes you make to your code. It’s a handy functionality when you’re actively
developing a new page, or making small visual tweaks that you want to preview in real time.

Historically, Remix did not offer support for HMR: that meant you had to manually refresh the page whenever you made
a change to your client-side or server-side code, which was old-school and time-consuming.

Luckily, that’s not the case anymore! Remix v2 ships with a new dev server that supports HMR and Hot Data Reloading
(HDR), the equivalent of HMR for server-side code. Whenever you make a change to your Hydrogen app, it will be
propagated immediately to your browser. Client-side state is also maintained, so that you can continue interacting with
the app without restarting any user flows from scratch (e.g., if you’re in the middle of checkout).

It has support for hot module replacement (HMR) and hot data reloading (HDR). The announcement is available
[on YouTube](https://www.youtube.com/watch?v=79M4vYZi-po).

On earlier versions of Remix, whenever there was a code change, you would have to manually refresh the page to see the
new changes (pretty old-school tech). Now, that is unnecessary and HMR will not reset client-side state between updates.
And HDR can be described as HMR for data loaders. With HDR you can make changes to your server code and see those
updates reflected in your UI immediately without resetting client-side state, just like HMR.

### Native Support for PostCSS and Tailwind and PostCSS

As you probably know, Hydrogen uses [Tailwind](https://tailwindcss.com/) as the default CSS framework.

Unlike more traditional CSS frameworks (such as Bootstrap), Tailwind relies heavily on CSS post-processing to generate
your final CSS build: it scans all your files, understands which Tailwind classes need to be generated, and then
generates just the classes you need. This allows you to minimize the amount of CSS you’re shipping to the client while
also allowing you to do incredible things, like attaching [arbitrary CSS properties](https://tailwindcss.com/docs/adding-custom-styles#arbitrary-properties).

Before Remix v2, you would have to run any CSS transformations in a separate process, e.g. with
[Tailwind’s CLI interface](https://tailwindcss.com/blog/standalone-cli), then import the final CSS file into your Remix
app. This worked, but wasn’t really a smooth development experience.

Remix v2 adds out-of-the-box support for [Tailwind directives and PostCSS](https://remix.run/docs/en/main/start/v2#built-in-postcsstailwind-support),
a popular CSS processor that Tailwind integrates natively with. If you’re using Hydrogen, all the relevant configuration
is generated for you: simply bootstrap your app, and your Tailwind styles will just start compiling automagically!

Check out Remix’s documentation about [PostCSS](https://remix.run/docs/en/main/styling/postcss) and
[Tailwind](https://remix.run/docs/en/main/styling/tailwind) for more details.

### Server-Side Streaming with `defer`

This one is a game-changer. Remix v2 aims to provide first-class support for React 18's SSR streaming capabilities
through the `defer` helper.

When you return a `defer` function call in a route loader, you are initiating a streamed response. This is very
useful when serving lower-priority data that may take longer to load. After all, you don’t want your users to wait on
slow data if more important content is ready to display on the page!

Here’s an example of what streaming looks like on the server:

```javascript
import { defer } from "@remix-run/node";

export async function loader ({ request }) {
  // Product info query is small, cached aggressively, ad
  // high priority for the user. Let’s go ahead and let it
  // resolve since it’s fast!
  let productInfo = await getProductInfo (rewquest);

  // Product reviews query is large and cache is more lax.
  // Let’s initiate the query but not wait for it to resolve.
  let productReviewsPromise = getProductReviews (request);

  // With defer, we initiate a streaming response. This allows
  // the user to access the resolved data (`productInfo`) as
  // soon as it’s available, while the unresolved product
  // reviews are loaded in the background.
  return defer ({
    productInfo,
    productReviewsPromise,
  });
}
```

The corresponding client-side code would then leverage the `Await` component, which is built on top of
[React’s `<Suspense />` API](https://react.dev/reference/react/Suspense):

```javascript
import { Await } from "@remix-run/react";

function ProductRoute () {
  let {
    // Product info has already resolved. Render immediately!
    productInfo,
    // Product reviews might not be ready yet 🤔
    productReviewsPromise,
  } = useLoaderData ();

  return (
    <div>
      <h1>{productInfo.name}</h1>
      <p>{productInfo.description}</p>
      <BuyNowButton productId={productInfo.id} />
      <hr />
      <h2>Reviews</h2>
      <React.Suspense fallback={<p>Loading reviews…</p>}>
        <Await resolve={productReviewsPromise} errorElement={<ReviewsError />}>
          {(productReviews) =>
            productReviews.map ((review) => (
              <div key={review.id}>
                <h3>{review.title}</h3>
                <p>{review.body}</p>
              </div>
            ))
          }
        </Await>
      </React.Suspense>
    </div>
  )
}

// Error fetching the data? Slow connection and timed out?
// Show an error message *only* for reviews. The rest
// of your product UI is still usable!
function ReviewsError () {
  let error = useAsyncError (); // Get the rejected value
  return <p>There was an error loading reviews: {error.message}</p>;
}
```

This was a framework-agnostic example, but Hydrogen is already leveraging `defer`. On the home page, for instance,
recommended products are streamed rather than being loaded immediately:

```typescript
export async function loader ({context}: LoaderArgs) {
  const {storefront} = context;
  const {collections} = await storefront.query (FEATURED_COLLECTION_QUERY);
  const featuredCollection = collection.nodes[0];
  const recommendedProducts = storefront.query (RECOMMENDED_PRODUCTS_QUERY);

  return defer ({featuredCollection, recommendedProducts});
}
```

For more examples of how Hydrogen leverages Remix features to optimize data handling, you can take a look at
[this article](https://hydrogen.shopify.dev/update/improving-data-handling-in-hydrogen-and-remix).

### Flat Routing by Default

Older versions of Remix use subfolders to nest route segments. This leads to a lot of directory nesting, and also makes
it harder to navigate the directory tree.

Remix v2 embraces [flat routing](https://remix.run/docs/en/main/start/v2#file-system-route-convention) instead. With
flat routing, all your routes are in the same directory, which makes it easy to find them at a glance. For example,
here’s the new folder structure in a Hydrogen application based on Remix v2:

![](https://cdn.sanity.io/images/kqgmf0g2/production/59ae846180e55976494ef64fb35b7ee854107044-698x1370.png?fit=clip)

There’s a bit more to it, so we encourage you to check out [Remix’s documentation](https://remix.run/docs/en/main/start/v2#file-system-route-convention)
about the change to fully understand the new folder structure.

Since not everyone will love this change, you can also maintain the current approach by installing the
`@remix-run/v1-route-convention` package and adding the following to your `remix.config.js`:

```javascript
const {
  createRoutesFromFolders,
} = require ("@remix-run/v1-route-convention");

/** @type {import ('@remix-run/dev').AppConfig} */
module.exports = {
  future: {
    // makes the warning go away in v1.15+
    v2_routeConvention: true,
  },

  routes (defineRoutes) {
    // uses the v1 convention, works in v1.15+ and v2
    return createRoutesFromFolders (defineRoutes);
  },
};
```

## How to Upgrade Your Hydrogen Application to Remix v2

Now, this is the part you were all waiting for! How difficult is it to upgrade an existing Hydrogen application to Remix
v2? Luckily for you, not very difficult.

The typical approach for performing major upgrades to your application’s dependencies typically involves creating a
separate, long-lived feature branch, working on the upgrade in isolation, and then releasing it all in one go.

![](https://cdn.sanity.io/images/kqgmf0g2/production/a7da987d49c9126fa8f5bc3dd60f94bbf867eea6-1516x634.png?fit=clip)

This approach, which is still very widespread, has several drawbacks:

- It is time-consuming, because it requires a lot of work and frequent rebases.
- It is prone to error, because you’re releasing a lot of changes in one deployment.
- It is all-or-nothing, because it prevents you from adopting new features before the upgrade.

Remix aims to fix this problem through [Future Flags](https://remix.run/docs/en/main/start/future-flags). Future flags
allow developers to incrementally adopt new features and then seamlessly upgrade their application, eliminating the need
for long feature branches and scary deployments.

Conceptually, the way they work is very simple: the Remix team releases Remix v2 features in Remix v1, but puts them
behind a feature flag that you need to manually enable in your Remix configuration. Then, when Remix v2 is released, the
Remix team simply removes all future flags and turns them into default behavior. This allows you to integrate one
feature at a time as it’s released by Remix, rather than doing it all in one pass.

![](https://cdn.sanity.io/images/kqgmf0g2/production/79ff3d1e16ca4fb2421871fa9cce3b5ba6a56599-1999x441.png?fit=clip)

For instance, here are the future flags for Remix v2:

```javascript
/** @type {import ('@remix-run/dev').AppConfig} */
module.exports = {
  //…
  future: {
    v2_dev: true,
    v2_meta: true,
    v2_headers: true,
    v2_errorBoundary: true,
    v2_routeConvention: true,
    v2_normalizeFormMethod: true,
  },
};
```

If you are on the latest version of Remix v1, your `remix.config.js` looks like the one above, and you’re not getting
any errors, you should be able to safely upgrade to Remix v2 by following the [official upgrade guide](https://remix.run/docs/en/main/start/v2).

If you haven’t enabled those future flags yet, then we strongly recommend doing so in the next few weeks so that you
can have a smooth upgrade path in front of you.

Note that the Hydrogen team still needs to officially release support for Remix v2, but thanks to future flags,
most of Hydrogen’s code is already compatible. All you need to do is upgrade the dependency in `package.json`, remove
the future flags in `remix.config.js`, and you should be good to go!

## What’s Next for Remix and Hydrogen?

In our work so far, we found the developer experience offered by Hydrogen through Remix is miles ahead of what we had in
Hydrogen v1. With a few lines of code, it’s possible to develop rich e-commerce experience while also abiding by web
standards and following modern UX practices. Because of that improvement, we’re very excited for the future of this
synergy!

The Remix team recently [announced](https://remix.run/blog/open-development) that they want to be more transparent about
their plans for the framework, but the [public roadmap](https://github.com/orgs/remix-run/projects/5) doesn’t offer a
lot of information yet. That means it’s still early to tell what other features might be coming up that Hydrogen
developers can benefit from.

One initiative on our radar is the [work](https://remix.run/blog/remix-v2#what-about-rsc) done by the Remix team to
integrate React Server Components (RSC). Unfortunately, this will take some more time, as RSC are still unstable and
won’t be included in Remix just yet as a result.

If you were waiting for more features or stability in order to start using Hydrogen, today is the best time to give it a
try! We’re sure you will be pleasantly surprised.

What Does Remix v2 Mean for Shopify Hydrogen Developers?

At the end of 2022, the entire frontend community was surprised by an unexpected announcement: [Shopify acquired Remix](https://shopify.engineering/remix-joins-shopify). At first glance, this news offers little information; after all, Shopify is famous for investing many resources into open-source projects. However, after further research, the reason for this merger became clear: Remix is deeply aligned with Shopify’s new framework: Hydrogen.

Shortly after the big news, the dev team behind Hydrogen [made another announcement](https://hydrogen.shopify.dev/roadmap/): the entire framework was being re-created from scratch using Remix, thus giving birth to Hydrogen v2. While the upgrade path will likely be a struggle for existing Hydrogen v1 users, Hydrogen v2 offers several benefits over its predecessor.

In this article, we’ll look at some of the most significant enhancements Hydrogen v2 brings to the developer experience, what they mean for your user experience, and how you can start adopting them in your storefront.

## A Brief Primer on Remix

To fully comprehend Hydrogen’s latest changes, we must first understand Remix.

For those unfamiliar with it, Remix is an up-and-coming Javascript framework based on React. It was developed by Kent C. Dodds, Ryan Florence, and Michael Jackson, all well-known contributors to the Javascript open-source community.

Unlike the previous generation of React frameworks such as Next.js, Remix is full-stack, monolithic, and fully server-side-rendered, and it will feel like a breath of fresh air to all the Ruby on Rails and Laravel lovers. In fact, Remix’s primary goal is to merge the benefits of the “old Web” with the smooth developer experience React offers. This way, developers get higher productivity, simpler code, better SEO, less backend-frontend communication overhead, smaller client bundles, and near-instantaneous page transitions.

![](https://cdn.sanity.io/images/kqgmf0g2/production/030082583dd37bf225378d98322d8b1993cf3e0b-2960x2400.png?fit=clip)

When developing the first version of Hydrogen, Shopify created a framework very similar to Remix in spirit: it was React-based, but it was also rendered on the server. This was a surprising choice back in the early days of Hydrogen, but it did make a lot of sense in retrospect: anyone who has tried to implement an eCommerce storefront quickly found that the dynamic nature of eCommerce doesn’t play well with static site generation and client-side rendering.

In October 2022, Remix announced that Shopify was acquiring it. As part of the deal, Shopify will offer continuous support to Remix’s authors to continue developing the framework, and Remix is becoming the React framework powering Hydrogen. On their side, Hydrogen’s development team can now delegate most of the core framework functionality to Remix, focusing only on Hydrogen-specific functionality.

## The Main Changes in Shopify Hydrogen v2

Even though the Shopify developer community (and Shopify themselves, [in some places](https://github.com/Shopify/hydrogen/blob/2023-04/packages/hydrogen/CHANGELOG.md#202317)) dubbed this release “Hydrogen v2”, this isn’t technically correct: Hydrogen simply follows calendar versioning, with each version number being a combination of the date and month of the release (e.g., v2023.1.0). However, for the sake of simplicity, we will refer to “Hydrogen v2” as the version of Hydrogen that uses Remix.

As you might expect, this release introduces _a lot_ of changes. In fact, pretty much everything in the framework has changed, meaning developers with an existing Hydrogen storefront have a whole bunch of rewriting to do.

### Retrieving Data with Loaders

The most significant change–which will affect pretty much every route in your project–is the introduction of Remix’s `loader` function.

The `loader` function is where all of your data retrieval logic is stored. The `useShopQuery` and `useQuery` hooks from Hydrogen v1, responsible for querying the Shopify Storefront API, have been replaced with `loader` in Hydrogen v2.

For example, imagine building a product detail page with a product options selector. In a typical React storefront, you would need to store the selected options in a state entry:

![](https://cdn.sanity.io/images/kqgmf0g2/production/e553a7b7b1f1e0d77e3cd95a9ecef7a1893b29c9-1200x520.png?fit=clip)

The problem with this implementation is that this component also needs to change the URL whenever a new variant is selected, so that users can easily bookmark or share the URL to the correct product variant. Unfortunately, there is no “native” way of achieving this with React. You would need to create a function that alters the URL when the user changes their selection.

With Remix, just like Ruby on Rails or Laravel, you can solve this by simply taking advantage of Web fundamentals. In this case, whenever the user selects a new product option, you simply direct them to a new URL, and the `loader` function gets executed again, querying the desired product variant from the Storefront API.

![](https://cdn.sanity.io/images/kqgmf0g2/production/3217fe54a31e57a20a6240808dd00e4937c4f7eb-1200x856.png?fit=clip)

The benefits of this new implementation are clear: we achieve the same outcome with less code and fewer abstractions to learn.

This approach was used to refactor all the major components in Hydrogen: the cart, analytics, SEO, and session management were rebuilt from scratch, resulting in a much more straightforward developer experience and a less steep learning curve!

[Learn more about the `loader` function in the Remix guides.](https://remix.run/docs/en/1.16.1/route/loader)

### Mutating Data with Actions

While the `loader` is used to _retrieve_ data, the `action` function is to _mutate_ data. As a consequence of segregating business logic into loaders and actions, you can now remove a bunch of code, especially client-side logic and state.

As an example, take a look at what the default `AddToCart` component looks like in the Hydrogen v1 demo store:

![](https://cdn.sanity.io/images/kqgmf0g2/production/253be981f9a0861351e4e2bcba39e77df56fec53-1374x2904.png?fit=clip)

And now, look at the same component in the Hydrogen v2 demo store:

![](https://cdn.sanity.io/images/kqgmf0g2/production/5c38c039f5c5132d9b9ba34c6d19d0b0075b7f0b-1424x1786.png?fit=clip)

As you can see, a lot of state management and querying logic has been removed in favor of a more straightforward implementation that relies on Web fundamentals such as... Web forms! This simplifies your code and makes your online store more resilient to network issues and more accessible to screen readers and old devices.

[Learn more about the `action` function in the Remix guides.](https://remix.run/docs/en/1.16.1/route/action)

### Handling Errors with Error Boundaries

A common and annoying problem with React applications is isolating errors. Typically, when you get any error on the frontend, the whole UI breaks, and the website becomes unusable. This is obviously not a desirable experience for our customers.

By taking advantage of Remix’s [nested routes](https://remix.run/docs/en/1.16.1/guides/routing#what-is-nested-routing), you can use [nested error boundaries](https://remix.run/docs/en/v1/guides/errors#nested-error-boundaries). If you export an error boundary function from a nested route and an error occurs, the error will be isolated, and the rest of your application will remain usable. This allows you to offer the best possible UX, even when things go wrong:

![](https://cdn.sanity.io/images/kqgmf0g2/production/e73f3849c1e52c9a44c721ff4b43976455174ab8-1207x1685.png?fit=clip)

[Learn more about error handling in the Remix guides.](https://remix.run/docs/en/1.16.1/guides/errors)

### Speeding Up Page Loads with Streaming

By using Remix’s [defer](https://remix.run/docs/en/1.16.1/guides/streaming#using-defer) function, you can easily decide which parts of your page should be rendered right away and which parts can be streamed after the page has loaded:

![](https://cdn.sanity.io/images/kqgmf0g2/production/d1fc77778b2760be478d391326acc7ede28f1abe-1207x1685.png?fit=clip)

This technique allows you to easily defer the loading of lower-priority parts of your UI, such as a “Related products” section on your PDP, making for a better user experience and faster loading times.

[Learn more about streaming in the Remix guides.](https://remix.run/docs/en/1.16.1/guides/streaming)

### Speeding Up User Interactions with Optimistic UI

Optimistic UI is a powerful technique that lets you completely hide loading states from the end user. For instance, when a user clicks on your Add to Cart button, rather than waiting for the cart to be updated on the server, you might immediately display the new item in the user’s cart. Then, if an error occurs, you can revert the state and display an error to the user:

![](https://cdn.sanity.io/images/kqgmf0g2/production/1cdb09cad49d184358eb840920173250a2061bc1-1250x800.png?fit=clip)

While not available yet, Hydrogen’s development team plans to adopt optimistic UI in all the standard components. Because Hydrogen is powered by Remix, you will also have the opportunity to use the same pattern in any custom user interactions you offer on your storefront.

[Learn more about optimistic UI in the Remix guides.](https://remix.run/docs/en/1.16.1/tutorials/jokes#optimistic-ui)

### Oxygen Is now Available to All Shopify Plans!

Although there was no official announcement, this is massive news for all Shopify developers! Hydrogen’s official deployment platform, [Oxygen](https://shopify.dev/docs/custom-storefronts/oxygen), which was only available to Shopify Plus users, is now available to all Shopify plans.

Oxygen is an excellent tool for engineers who want a seamless deployment and hosting experience. By keeping your storefront within Oxygen, you can not only reduce your infrastructure costs, but also have access to a fantastic developer experience that includes:

* Preview environments for testing changes in isolation.
* Custom environments (e.g., if you want a staging area).
* Version control and GitOps for your storefront.
* A Content Delivery Network (CDN) powered by Shopify.
* Support for both backend and frontend code.
* CI/CD via GitHub Actions and the Hydrogen channel.

If you’re familiar with Vercel, you’ll find that Oxygen offers a very similar development experience, but more accurately tailored to the needs of Shopify developers.

## Migrating from Hydrogen v1 to Hydrogen v2

If you are using Hydrogen v1 today, there’s a [handy migration guide](https://shopify.dev/docs/custom-storefronts/hydrogen/migrate-hydrogen-remix) in the Hydrogen docs that you can follow to upgrade your storefront.

The process takes a lot of effort, but the guide is comprehensive and accurate, so you should be able to upgrade your Hydrogen app by simply following the steps outlined.

## Is Hydrogen Ready for Production Use Yet?

That depends on your risk tolerance!

On a technical level, both Hydrogen and Oxygen are most definitely production-grade products, and they are being used successfully in the wild by large Shopify stores such as [Allbirds](https://hydrogen.shopify.dev/case-studies/allbirds). The developer experience is pleasant and powerful, and Shopify’s hosting infrastructure will easily handle any production load you throw at it.

On the other hand, it’s unclear whether Hydrogen will see any more extensive refactorings, such as the one we’ve just witnessed. As an example, [Remix v2](https://remix.run/docs/en/main/pages/v2) will be released soon, bringing many improvements over its predecessor, but also requiring developers to upgrade to a new API and file naming convention. These changes will most likely affect Hydrogen users as well. It’s also unclear what synergies Shopify will create between Hydrogen and [Commerce Components](https://www.shopify.com/commerce-components), but we expect some movement there.

![](https://cdn.sanity.io/images/kqgmf0g2/production/e038f0246b07a894d83a8ae5cb1d3fe545d2bc6a-2960x2335.png?fit=clip)

Another factor to consider is how long it will take for the Shopify app ecosystem to catch up to Hydrogen’s philosophy. While some Shopify apps don’t need to worry about the frontend at all, others will have to expose an API or JavaScript SDK of some sort to be usable with a headless commerce architecture. We expect the situation to improve over the coming years, but there’s still a long way to go, and many Shopify apps today cannot be used with Hydrogen.

Overall, Hydrogen is well worth a try if you have the engineering firepower. It solves a significant number of problems for Shopify developers and gives brands unmatched flexibility in building a custom storefront, allowing them to create shopping experiences that would be very hard to replicate with Liquid themes.

However, if you’re a small brand and don’t have the resources to invest in experimental technology, you’re probably better off sticking with Liquid themes until Hydrogen becomes a true first-class citizen in the Shopify ecosystem.

Shopify Just Released Hydrogen v2. What’s In It for You?

While the total penetration of headless commerce in the US is still low, we have witnessed an increase in headless builds in recent years. And even though [we don’t believe headless is the end-all solution to all eCommerce problems](https://nebulab.com/blog/headless-commerce), we think it’s about time the industry realized the power of this architecture and started using it responsibly.

The only way for Shopify users to go headless for a long time was to implement their own single-page application from scratch, using a JavaScript library such as React (and hopefully a framework, such as Next.js). Shopify does provide SDKs to make the API integration work slightly more manageable, but that was about it: until recently, there was very little being done for performance, state management, personalization, or SEO.

In November 2021, Shopify released a developer preview of [Hydrogen](https://hydrogen.shopify.dev/), their new framework meant to address precisely these problems. Here at Nebulab, we’ve recently had the chance to take Hydrogen for a spin, and we want to share our learnings.

## What is Hydrogen?

Hydrogen is an open-source, React-based framework that can be used to build custom storefronts on the Shopify platform. It provides a lot of useful functionality:

* A sensible structure for your application code.

* eCommerce-specific components and pages.

* An SDK and hooks to interact with Shopify’s GraphQL-based [Storefront API](https://shopify.dev/api/storefront).

* It uses [Tailwind CSS](https://tailwindcss.com/) for styling.

* It’s optimized for high-performance builds.

Combined, these features almost entirely eliminate the amount of boilerplate code engineers need to write to build their storefronts and allow engineers to spend most of their time on functionality that truly moves the needle.

![Shopify Hydrogen website](https://cdn.sanity.io/images/kqgmf0g2/production/9865cb4da04e7cd861e38c97cc7015d8ea7a1e22-2560x2512.png?fit=clip)

## What are the pros of using Hydrogen?

For Shopify stores that want to go headless, Hydrogen is a huge help. As we’ve mentioned, it abstracts away all the complexity of integrating with the Shopify API and developing your storefront’s skeleton: all you need to do is clone the Hydrogen [demo store](https://shopify.dev/custom-storefronts/hydrogen/getting-started/templates#demo-store-template), configure it, then focus on styling and custom functionality. This alone is a huge productivity boost, and the developer experience has been outstanding in our experiments.

It’s also important to note that Hydrogen is officially developed and supported by Shopify, which should provide peace of mind to brands looking for a stable, robust solution that’s not going anywhere. While some Shopify-specific Next.js templates already existed before Hydrogen, they were mostly small, community-sponsored projects, which made them unsuitable for enterprise use.

## What are the cons of using Hydrogen?

Seasoned developers know that productivity comes with a hidden cost: the more a tool tries to abstract away technical complexity, the more opinionated it is. When it comes to Hydrogen, it’s exceptionally opinionated:

* It uses React server components.

* It uses streaming server-side rendering (SSR).

* It has built-in components, hooks, and caching mechanisms.

* It’s heavily coupled with Shopify’s Storefront API.

* If you need complete control over your React application, Hydrogen is most likely not a good candidate for you.

You should also know that some of these features are bleeding edge in the React ecosystem, and because Hydrogen is tightly coupled with Shopify, the community around it is still relatively small. Hydrogen brands can expect to have a harder time finding online resources and support, and they will have to tap into a smaller pool of agencies and engineers than if they used a more popular framework. That said, much of that will likely change as Hydrogen gains popularity.

Finally, most Shopify Apps and plugins were built to integrate with Liquid templates and won’t be compatible with Hydrogen (or other headless architectures, for that matter). If you rely heavily on specific apps and your app doesn’t provide an API your engineers can integrate with, you’ll need to switch to a headless-friendly alternative or build the functionality yourself.

## Can Hydrogen be used without Shopify Plus?

It’s complicated. The official answer is yes: since Hydrogen is an open-source project whose source code is available to anyone, and because none of the API endpoints it uses are restricted to Shopify Plus customers, at first glance, the framework can be used without Shopify Plus.

In reality, things are more nuanced.

![Shopify Oxygen documentation](https://cdn.sanity.io/images/kqgmf0g2/production/a893aabf4ed6f21f992598100837e4856353c79f-2560x1620.png?fit=clip)

First of all, there’s the matter of hosting your Hydrogen application. Plus users can host their Hydrogen app on [Shopify Oxygen](https://shopify.dev/custom-storefronts/oxygenhttps://shopify.dev/custom-storefronts/oxygen), Shopify’s proprietary hosting solution, which provides native support for directing users who visit your Shopify domain to your Hydrogen storefront.

If you don’t use Shopify Plus, you should still be able to deploy your Hydrogen app to other platforms, but it won’t be a painless experience. For example, Vercel has published a blog post announcing the availability of a [zero-configuration deployment for Hydrogen](https://vercel.com/changelog/hydrogen-projects-can-now-be-deployed-with-zero-configuration). But when we tested it, we had to manually tweak the environment variables used by Hydrogen to match the names used by Oxygen. This was a minor inconvenience overall, but it shows how support for Hydrogen is still in its infancy.

Once you’ve figured out the hosting, it’s time to deal with domains and DNS records. If you manage your domains through Shopify, Shopify will attempt to redirect any requests to your [myshopify.com](http://myshopify.com/) domain to your Hydrogen storefront, which will completely break the checkout. This could be easily solved by using a [routing domain](https://help.shopify.com/en/manual/domains/domain-type/routing-domain) which, ironically, is only available to Shopify Plus customers. (When we reached out to Shopify engineering about this catch-22-esque paradox, they seemed utterly taken aback by this realization.) The current solution is to set up your Liquid storefront to redirect to your Hydrogen storefront via JavaScript, which is far from ideal.

Another aspect to consider is support: in our experience, if you’re not a Shopify Plus customer, you’re only going to get extremely limited technical support from Shopify, with most requests being redirected to Shopify’s Discord community. No one in the Discord community seems to have much experience with Hydrogen, except for Shopify’s own employees, whose presence in the community is very erratic.

To be fair, Shopify did tell us that they are working to address these challenges and make Hydrogen truly available to non-Plus customers. However, _when_ this will happen exactly is unknown.

To sum it up, if you’re not on Shopify Plus and don’t have an experienced engineering team or agency backing you up, we would advise against using Hydrogen right now: you run the risk of spending weeks or months of development only to run into deal-breaking roadblocks.

![Shopify Discord](https://cdn.sanity.io/images/kqgmf0g2/production/ce5f2c4f4565702286b8a1df6cd0d17d418c8538-2560x2068.png?w=450)

## Who should be using Hydrogen?

Shopify’s Hydrogen framework is the perfect solution for online stores that are already running headless, or are planning to go headless, can count on a robust engineering team, and want to lean into a powerful, officially-supported solution that will spare them from boilerplate work. The developer experience is enjoyable, and most React engineers will be more than happy to work on a Hydrogen app.

If, on the other hand, you don’t have an experienced engineering team or don’t want to deal with the complexity that comes with a headless solution, Hydrogen is not a good choice: as much as it simplifies things, it will still require much more upkeep than a Liquid-based Shopify build.

At this point, Hydrogen is also a less-than-ideal solution for brands not on Shopify Plus due to missing functionality and limited support from Shopify. That is likely to change as the framework matures and becomes more widely available, so keep an eye out for any announcements from Shopify (and from us!).

If you’re considering going headless with Hydrogen or other frameworks, and are unsure of the implications, [feel free to reach out](https://nebulab.com/contact-us)! Our team has extensive experience and will help you make the choice that best supports your digital strategy.

The Nebulab