DEV Community: Nathan Allen

Why We Kept Shopify: Connecting Content, Classes and Commerce for a Fitness Retailer

Nathan Allen — Fri, 30 Oct 2026 10:38:32 +0000

Before recommending any change, we needed to know whether the storefront was failing. That question decided the whole project. A rebuild fixes storefront limits, but it does nothing for gaps between systems.

The client was a US fitness retailer with about 30 employees. It sold equipment online through Shopify. It also offered digital training programs and outdoor workout classes.

What We Found in the Existing Setup

We reviewed Shopify commerce, fitness content, class registration tools, and HubSpot marketing. Shopify handled products, shopping carts, and secure checkout. Everything else lived elsewhere.

Workout programs, coaching information, and class schedules were maintained separately from the store. Nothing linked content, products, and classes into a clear path. A customer reading about a program had no direct route to buy gear or register.

Customers often navigated separate pages to purchase equipment or book a class. Internally, the team maintained duplicate content across disconnected systems. Marketing also lacked a connected view of customer movement between content, purchases, and bookings.

Why We Kept the Existing Commerce Platform

The review showed that the main issue was poor coordination between systems. It was not the Shopify storefront. Products, carts, and checkout were doing their jobs.

Replacing Shopify would have meant rebuilding functions that already worked. The retailer needed content, products, and classes to work as one customer journey. It did not need a new transaction engine.

Keeping the storefront also kept the project practical for a mid-sized business. We connected the existing systems instead of replacing any of them. That decision shaped every step that followed.

How We Defined the System Responsibilities

Once we kept Shopify, the next question was ownership. Each system needed a clear role. Without one, the same information would keep living in several places.

Shopify: products, shopping carts, and secure checkout
Strapi CMS: workout programs, trainer profiles, articles, and class information
HubSpot: customer segmentation and email marketing
APIs: connections between fitness content, Shopify products, and class-registration tools

The fitness content was the piece with no real home. Moving it into Strapi gave it a structured place to be managed. Shopify stayed the owner of commerce. This Strapi Shopify integration worked because neither system took over the other’s job.

How We Connected the Workflows

The integration brought together four elements: commerce, content, marketing, and registration. Each had a defined role within the overall system. We left the existing registration tools in place and connected them instead of replacing them.

APIs linked Strapi content to relevant Shopify products and to the class-registration tools. Content could now lead customers toward equipment and bookings. Those links removed the need to hunt across separate pages.

Structured content also fed HubSpot’s work. With content, purchases, and bookings better coordinated, marketing could support stronger segmentation. That allowed more relevant follow-up emails.

What Changed After Implementation

The results were operational and qualitative. Fitness content connected with Shopify shopping journeys. Equipment purchases and class registrations became easier for customers to reach.

On the team side, content management became simpler across four fitness content areas. Duplicate content updates were reduced. Strapi gave the team one structured place to manage workout programs, trainer profiles, articles, and class information.

HubSpot supported more relevant customer marketing. The improvements covered customer convenience, simpler daily operations, and more sales opportunities. We did not measure revenue or conversion changes, so I won’t claim any.

What This Project Reinforced for Me

Integration has costs. Every connection is a dependency, and someone must own it as platforms change. Teams also need clear rules for which system owns each piece of information.

A separate CMS is not right for every store. If content is simple and rarely tied to products, Shopify’s native tools may be enough. If the storefront itself blocks a required feature, larger changes make sense.

For this retailer, the problem sat between systems. So I now ask where friction lives before suggesting a replacement. Write down what each system should own, then look at where information crosses boundaries.

Read Full Case-Study:- Strapi & Shopify Integration for a Fitness Retailer

Duplicate Support Actions Caused by Unhandled Webhook Retries

Nathan Allen — Mon, 19 Oct 2026 09:28:41 +0000

The webhook endpoint returns success, the support ticket appears, and everything looks normal. Then the same ticket is created again. This can happen without a faulty model because webhook delivery and business-event processing have different reliability guarantees.

Consider a hypothetical ecommerce order event that creates a customer-service ticket and sends a confirmation message. If the platform retries that delivery, the handler may repeat both actions. This article follows that failure through event identity, PostgreSQL constraints, durable work and tests.

Why Successful Webhook Delivery Does Not Guarantee Single Processing

Webhook providers generally promise at-least-once delivery, not exactly-once delivery. If your endpoint times out, returns an error, or loses the connection before the provider records your acknowledgment, the provider cannot know whether you processed the event, so it sends it again.

The dangerous case is a handler that does the work before responding. It creates the ticket, then a slow database call delays the response past the timeout. The provider sees a failure, the ticket already exists, and the retry creates another.

I separate two ideas here. Receiving an event means the payload arrived and was stored. Completing the business action means the ticket exists exactly once and the customer was notified once. Acknowledgment should depend on the first, never on the second.

Choosing the Correct Event Identifier for Deduplication

Shopify’s webhook delivery documentation describes X-Shopify-Webhook-Id as the identifier for an individual webhook delivery, which makes it the natural key for rejecting a repeated delivery. Treat it as a delivery key; other platforms name and scope identifiers differently, so verify each provider.

X-Shopify-Event-Id serves a different purpose. Per the same guidance, it correlates deliveries that arise from one merchant action. If an app has several subscriptions for the same change, each delivery can carry its own webhook ID while sharing an event ID.

Neither header is your business operation identity. I derive a separate key, such as ticket:order_id:topic, for the action itself. The delivery ID stops repeated deliveries, while the operation key stops two different events from opening two tickets for one need.

Preventing Duplicate Actions with Persistent Idempotency

Idempotency means repeating an operation leaves the same result as performing it once. In PostgreSQL, I enforce it with a unique constraint on the delivery ID, so the database, not application memory, decides whether an event is new, even across multiple servers.

The handler inserts the event row and returns quickly. A separate worker claims pending rows and performs the ticket work, a pattern I look for when reviewing ecommerce AI chatbot solutions. Storing the event and its job in one transaction keeps both together.

Workers can crash, so claims need recovery. I record a claim time and let another worker reclaim rows stuck in processing beyond a timeout. That recovery guarantees eventual progress, but it also means the same job can run twice.

sql
CREATE TABLE webhook_events (
  webhook_id text PRIMARY KEY,
  payload    jsonb NOT NULL,
  status     text NOT NULL DEFAULT 'pending',
  claimed_at timestamptz
);

js
// Illustrative only. HMAC verification omitted. Review and test before use.
await db.query(
  `INSERT INTO webhook_events (webhook_id, payload)
   VALUES ($1, $2) ON CONFLICT (webhook_id) DO NOTHING`,
  [req.get('X-Shopify-Webhook-Id'), req.body]
);
res.sendStatus(200); // new or duplicate: the event is safely stored

sql
-- Atomic claim; SKIP LOCKED keeps concurrent workers off the same row
UPDATE webhook_events SET status = 'processing', claimed_at = now()
WHERE webhook_id = (
  SELECT webhook_id FROM webhook_events
  WHERE status = 'pending'
     OR (status = 'processing' AND claimed_at < now() - interval '5 minutes')
  ORDER BY claimed_at NULLS FIRST
  LIMIT 1 FOR UPDATE SKIP LOCKED)
RETURNING *;

*The Race Condition in Check-Then-Insert Logic
*
A SELECT followed by an INSERT is unsafe. Two concurrent workers can both run the SELECT, find nothing, and then both INSERT before either commits. A unique constraint makes the second insert fail atomically, which closes the gap.

Handling Failures Between Event Storage and Ticket Creation

A transaction makes database state transitions atomic, but it cannot roll back a call to a remote ticketing API. If a worker creates the ticket and crashes before marking the row done, recovery reruns the job and creates a second ticket.

The durable work queue, often called an outbox, records intended side effects in the same transaction as the state change. Where the ticketing API supports idempotency keys, send the operation key with each request so repeated calls can return the original ticket.

Without downstream idempotency, I would reconcile instead. Before creating a ticket, search the ticketing system for the operation key stored in a custom field or tag. This reduces duplicates but is not perfectly atomic, so concurrent workers still need a claim.

Testing Replayed and Concurrent Webhook Deliveries

Replay tests turn these assumptions into checks. Run each scenario against a test database and a fake ticketing service that counts calls. The assertion is always the same: one ticket and one notification per business operation.

Duplicate deliveries: post the same payload with an identical webhook delivery ID several times and expect one stored row and one ticket.
Concurrent processing: start parallel workers on one pending event and expect exactly one successful claim.
Crash after ticket creation: kill the worker before recording completion, then confirm recovery does not create a second ticket.
Unprotected downstream retries: make the fake API time out after succeeding and confirm reconciliation finds the existing ticket.

Run the concurrency case many times, because races appear intermittently. A single passing run proves little, while a repeated failure usually points to a missing constraint, an unclaimed job, or an unguarded side effect in the worker.

Idempotency Must Cover the Business Action

The engineering test is simple. Retrying the same delivery, at any moment and from any worker, must not duplicate the intended business operation. Delivery IDs, unique constraints, durable queues and downstream keys each cover one failure mode, and none replaces the others.

Also observe real outcomes, not only logs. Count tickets and customer messages per order in the ticketing system and the email provider, because a successful insert in your own database never proves what happened in an external API.

Headless Ecommerce Is Easy to Explain. System Ownership Is the Hard Part.

Nathan Allen — Mon, 12 Oct 2026 09:08:41 +0000

A headless ecommerce diagram looks clean. A Next.js storefront on top. A commerce API underneath. Two boxes and one arrow.

Production rarely stays that tidy. Search arrives. Then a CMS, an ERP, a PIM, inventory rules, promotions, tax, analytics, and personalization. Every new box brings its own failure modes.

When I review these architectures, decoupling is rarely the hard part. Ownership is. The better question is not “should we go headless?” It is this: when we decouple the storefront, which responsibilities did we actually move, and who owns them now?

Headless Does Not Remove the Backend

Separating the storefront removes the theme layer. It does not remove the work the platform was doing. Checkout, pricing, inventory, customer accounts, orders, fulfillment, tax, promotions, and product data still exist. They need a clear home.

In a traditional setup, the commerce platform owns most of that by default. The theme calls platform code directly. When something breaks, there is usually one place to look.

After decoupling, the same responsibilities can spread across several systems and several teams. This is the diagram most proposals show:

Customer
↓
Next.js / React Storefront
↓
API Layer
├── Commerce
├── CMS
├── Search
├── ERP
└── Inventory

The diagram is easy. The questions it hides are not:

Which system is authoritative for price and stock?
Who owns the failure when one API is down?
What happens when inventory sync is delayed?
What happens when CMS content references a removed product?
What happens when pricing differs by region?

If the team cannot answer these before the build, it will answer them during an incident.

Platform choice does not settle this either. Shopify’s Hydrogen is built on React Router and works with the Storefront API and Customer Account API. BigCommerce’s Catalyst is built with Next.js on its GraphQL Storefront API. Both give you a solid frontend starting point. Neither decides ownership for you.

Three Problems That All Get Called “Headless”

The request sounds identical every time: “we need headless.” The underlying problems are not identical. I try to separate them first. For the business side of that decision, see headless ecommerce vs traditional ecommerce.

1. A frontend problem

The store has a slow theme, heavy scripts, and a dated design. But the catalog is standard. Pricing is standard. Checkout works. There is one storefront and few integrations.

Here the constraint is frontend engineering. Clean up the theme, audit third-party code, fix images and caching. A new architecture would add a deployment pipeline and an API layer to solve a problem that better frontend work can solve.

2. An experience problem

Marketing needs buying guides, product education, campaign pages, and flexible layouts. Every idea has to fit theme templates, and every test needs a developer.

This is where separating presentation from commerce starts to pay off. Commerce keeps products, carts, and checkout. A CMS and a custom frontend own the experience. Each side can then change without forcing the other to move.

3. An architecture problem

The business has an ERP, a PIM, regional pricing, B2B rules, and fulfillment systems. Orders and stock move between tools. Middleware keeps growing.

This is bigger than a frontend decision. The storefront is one consumer of a wider system. The real work is deciding where pricing, inventory, and orders live and how those systems agree with each other.

Headless Is Not a Performance Strategy by Itself

A Next.js storefront can still be slow. I would not assume otherwise because the repo is modern.

Real storefronts collect analytics, tag managers, review widgets, personalization, and ad scripts. Slow APIs and uncached calls add latency. Oversized images and heavy client-side JavaScript add more. A decoupled frontend can carry all of that, and sometimes adds new network calls on top.

Performance depends on engineering: rendering strategy, caching, image delivery, API response times, and script discipline. Headless gives you control over those. It does not do the work for you.

Headless and Composable Solve Different Levels of Separation

Headless separates presentation from the commerce backend. That is one cut.

Composable architecture makes several cuts. Commerce, CMS, search, PIM, ERP, personalization, and analytics can each be a separate service with its own owner. You choose the best tool per capability and connect them through APIs.

That flexibility is real. So is the cost. Each additional cut adds integrations, monitoring, vendor relationships, and another place for data to drift. I treat headless as one decision and composable as a bigger one. They should not be bought together by default.

What a CMS Should and Should Not Own

Content is often the first thing teams separate, and for good reasons. Buying guides, landing pages, FAQs, campaign copy, and regional editorial content change often. Editors need previews and structure, not a deploy.

A well-planned headless CMS architecture gives that content a proper home. But the CMS should not quietly grow into a second commerce system.

Pricing, inventory, customers, checkout, and orders belong to commerce or to the operational systems behind it. When a CMS stores its own copy of a price or stock level, you now have two sources of truth. One of them will be wrong at the worst time.

The safer pattern is to store references. CMS content points to a product ID. The frontend fetches live commercial data from the commerce API and combines it with editorial content at render time.

Next.js supports this with on-demand revalidation by tag or path. A CMS webhook can trigger it when content changes. That keeps pages fresh without rebuilding everything. It also creates a dependency someone must monitor.

A Rough Decision Table

This is a starting point, not a rulebook.

Decoupled Technology, Undecoupled Responsibility

This is where distributed architecture turns into distributed confusion. The technology is separated. The responsibility is not.

Here is the pattern I look for in reviews. A price looks wrong on the storefront. Is it the commerce platform, the ERP sync, a regional price list, or a stale cache? If four teams each own a piece and nobody owns the path, the answer takes hours.

Or take inventory. The ERP is authoritative, but the commerce platform shows stock. A sync runs late. The storefront sells something that is gone. Who decides what customers see when the data is uncertain?

I want a written answer to a few things for every system in the stack:

What is it the source of truth for?
Who owns its uptime and its upgrades?
What does the storefront show when it fails?
How do we detect that it faile d?

None of this is exciting. All of it decides whether the architecture survives its second year.

When I Would Not Go Headless

I get cautious when:

The store has standard requirements
The existing platform handles checkout well
One storefront is enough
Integrations are limited
The theme can support the experience the business needs
No engineering team owns the extra infrastructure Sometimes keeping the monolith is good engineering. A simpler system with clear ownership beats a flexible one nobody can explain.

The Question I Start With

Headless gives teams real freedom over the frontend, the content, and the integrations. That freedom is valuable when a specific constraint justifies it.

So I start with one question. What is the current platform preventing us from doing cleanly? If the answer is a theme, fix the theme. If it is content freedom, separate content. If it is operations, look behind the storefront.

How have you decided where pricing and inventory live once the storefront was decoupled?

I Like Strapi for Ecommerce. I Still Wouldn't Start With Strapi.

Nathan Allen — Thu, 08 Oct 2026 10:17:55 +0000

I wouldn't start with Strapi.

I wouldn't start with Sanity, Payload, or any other CMS either. The first decision in an ecommerce stack isn't the CMS. It's simpler than that. Which system owns each piece of data?

Teams skip that question because choosing a tool feels like progress. Content types get modeled. Pages get built. Then two systems quietly start storing the same price.

Ownership Comes Before the Tool

Before I look at any CMS, I list what the business actually stores. Products and variants. Prices and promotions. Inventory. Cart, checkout, and orders. Editorial content. Search indexes. Customer data. Anything the ERP or PIM already holds.

Then I ask three questions about each item. Who writes it? Who reads it? What should the storefront do when the owner is down?

The last question matters most. It's easy to say "the commerce backend owns prices." It's harder to decide what the page shows when that backend times out.

What Overlapping Ownership Looks Like

*Here's a stack I'd call reasonable:
*
Storefront (Next.js)
├─ Strapi → editorial content
├─ Medusa → products, prices, carts, orders
├─ ERP → warehouse stock
└─ Search → indexed catalog

Each box has one job. Strapi holds guides, campaigns, and FAQs. Medusa runs commerce. The ERP owns stock. Search owns discovery.

Now add one shortcut. A marketer wants a sale price inside a campaign banner. Someone adds a price field to the Strapi content type. Both Strapi and Medusa can now hold an editable price.

That's where the trouble starts. A sync job gets written. It runs late, or it fails quietly. Say the banner shows 49 and the cart shows 59. No CMS feature fixes that. It's an ownership bug.

The Architecture Mistake I See Most Often

The mistake is modeling content before deciding ownership. It feels harmless. A "Product Highlight" type with name, price, stock status, and image looks useful on day one.

Later, those fields drift. Names change in the commerce backend. Stock changes in the ERP. Editors fix what they can see, and nobody trusts the data anymore.

Now I write a one-page ownership table first. Every field gets one owner. If the CMS doesn't own a field, it doesn't get a copy of it. It gets a reference.

Store References, Not Copies

A reference is usually a product handle or ID. The CMS stores which product, not what the product is.

`// Editorial content comes from Strapi
const campaign = await strapi.getCampaign(slug);

// Product facts come from the commerce backend
const products = await commerce.getProducts(campaign.productHandles);`

This keeps one source of truth. But it has a cost. Every campaign page now needs two requests. Previews need commerce data too. If the commerce API is slow, the campaign page is slow.

So I decide the failure behavior up front. If products don't load, the page should still show the editorial content. The product block can hide or fall back. A buying guide shouldn't return a 500 because a price service had a bad minute.

I'd rather accept two requests than maintain two prices. But it's a tradeoff, not a free win.

Webhooks, Caching, and Stale Content

Once content and commerce live apart, freshness becomes your job. Strapi can send webhooks on events like entry.create, entry.update, entry.publish, and entry.unpublish. For most events, the payload contains the full entry with its relations and components.

A common pattern is to call your frontend when an editor publishes. The frontend then revalidates the affected page. In Next.js, that's on-demand revalidation.

Two details matter to me. First, secure the endpoint. Strapi lets you configure webhook headers, so verify them. Second, don't treat a webhook as a guarantee. I'd add a scheduled reconcile job, so one missed event doesn't leave a page stale for days.

Preview needs thought too. Editors want to see drafts. The preview route has to read draft content from Strapi and still fetch live commerce data. Test that path early. In my experience it breaks more easily than the published path.

Where Strapi Earns Its Place

I like Strapi when content needs real structure. Components and Dynamic Zones let editors assemble pages from approved blocks. REST and GraphQL let each channel request what it needs. Backend customization is real, and you can self-host it.

Next to Medusa, the split is clean. Medusa handles products, variants, pricing, carts, and orders through its commerce modules. Strapi handles guides, campaigns, FAQs, and reusable blocks. Different problems, different systems.

But using both increases what you own. That's two deployments, two upgrade paths, two permission models, and one more integration to monitor. Strapi 5 also changed core APIs, so I check version support before depending on any community plugin. If you want a closer look at the implementation side, this page on Strapi development services covers content models, integrations, and upgrades.

When I Wouldn't Add Strapi

The commerce platform already covers your content needs
Nobody owns hosting, upgrades, and security
The team wants fully managed infrastructure
Another CMS fits your editor workflow better
The design needs the CMS to duplicate operational data

The last one is a design problem, not a tooling problem. If the plan requires copying prices or stock into the CMS, I'd fix the plan before choosing software.

What I Ask Before Installing Anything

Who owns each field? What happens when that owner is unavailable? How does a content change reach the storefront? Who patches the CMS? Who owns the integration between systems?

If I can't answer those in plain language, the CMS isn't the next step. A missing answer usually means two systems will fight over the same data later.

The Principle I Keep

I still like Strapi. I just don't start there anymore.

I start with one page that says who owns what. Once that page is honest, the CMS choice gets smaller and calmer. Sometimes the answer is Strapi. Sometimes it's something simpler. Either way, the stack has fewer arguments waiting to happen.