When an online purchase goes wrong (a slow product page, a cart that forgets an item, a discount that doesn't apply), the shopper doesn't care whether it was a frontend or a backend problem. You should, because it decides who fixes it, what it costs and which tools are involved. This post explains both halves of a modern store in plain terms, using Shopify as the worked example, for founders and managers who brief developers.
Key takeaways
- Frontend is what runs in the shopper's browser: pages, interactions, the cart drawer. Backend is what runs on servers: catalog, inventory, pricing, orders, payments and integrations.
- On Shopify, the platform runs the core backend and the checkout. Your team customizes the frontend (a Liquid theme, or a headless app) and extends the backend through APIs, webhooks, apps and Shopify Functions.
- The two halves talk through APIs. Themes use the Ajax Cart API and the Section Rendering API, headless storefronts use the GraphQL Storefront API, and back-office integrations use the GraphQL Admin API.
- Most store problems sit at the seams: scripts slowing the frontend, or integrations falling out of sync on the backend. Design those seams on purpose.
The frontend: everything the shopper touches
The frontend is the presentation layer. It's built in HTML, CSS and JavaScript, and it's responsible for:
- Rendering product, collection, search and content pages
- Interactions: variant pickers, image galleries, filters, the mini-cart
- Speed and stability, measured by Core Web Vitals
- Accessibility: keyboard use, screen readers, contrast and labels
On a standard Shopify store, the frontend is a theme. Shopify renders Liquid templates on its servers and sends HTML to the browser, and JavaScript then adds the interactive parts. Themes are organized into layouts, templates, sections, blocks and snippets, so merchants can rearrange pages in the theme editor without code.
The alternative is a headless frontend, a separate app (often React) that you host. It fetches data through Shopify's Storefront API. Shopify's toolkit for this is Hydrogen, whose current template uses React Router 7 and deploys to Shopify's Oxygen hosting.
The backend: the system of record
The backend stores and enforces the facts of the business:
- Products, variants, prices, inventory and locations
- Customers, carts, orders, refunds and fulfillment
- Discounts, taxes, shipping rates and payment processing
- Connections to other systems: ERP, warehouse/3PL, email and SMS, accounting, POS
The difference with Shopify is that you don't build or host this backend. Shopify runs it, along with checkout and payments. Your team extends it in four main ways:
- GraphQL Admin API. Read and write store data from apps and integrations. Shopify marked the REST Admin API as legacy in October 2024, and new public apps must use GraphQL.
- Webhooks. Shopify notifies your systems when something happens (
orders/create,products/update), over HTTPS, Google Pub/Sub or Amazon EventBridge. - Shopify Functions. Small programs that Shopify runs inside its own backend to customize discounts, delivery and payment options, and cart and checkout validation. They replaced Shopify Scripts, which stopped running on June 30, 2026. See my Shopify Functions guide.
- Apps. Public apps from the App Store, or custom apps for a single store, which combine the pieces above with their own servers and UI.
How they collaborate: one "Add to cart" click
Here is what happens when a shopper adds a product to the cart on a typical Online Store 2.0 theme:
- Server render. Shopify renders the product page from Liquid, using live backend data: price, availability and variant options.
- Interaction. The shopper picks a variant. A small JavaScript component (often a custom element, as in Shopify's Dawn theme) updates the selected variant in the page.
- API call. The component sends a
POSTrequest to/cart/add.js, part of Shopify's Ajax Cart API. - Backend logic. Shopify validates the request, adds the line item, and applies any automatic discounts. Discounts built with Functions run here, on Shopify's servers.
- Fresh HTML. The same request can ask for up to five theme sections to be re-rendered, which the docs call bundled section rendering. The response includes updated cart drawer HTML, so the frontend just swaps it in.
- Downstream. When the order is placed, a webhook tells your ERP or 3PL. Shopify's docs advise against relying on webhooks alone and recommend periodic reconciliation jobs, because a delivery can be missed.
In a headless store, steps 1, 3 and 5 change. Your app renders the page and calls the Storefront API's cart mutations instead. Steps 4 and 6 stay the same, because the backend is still Shopify.
Pro tip: If a bug report says "the price is wrong," first check whether the backend has the right price (the admin, or an API query). If it does, the problem is frontend rendering or caching. That one question halves debugging time.
Common technologies on each side
| Layer | Shopify theme store | Headless Shopify store | What it's for |
|---|---|---|---|
| Page rendering | Liquid (server-side, on Shopify) | React/Hydrogen or another framework, on Oxygen or your own host | Turning data into HTML |
| Interactivity | Vanilla JS, custom elements | React components | Variant pickers, filters, carts |
| Storefront data | Liquid objects, Ajax Cart API, Section Rendering API | GraphQL Storefront API | Products, cart and search in the browser |
| Back-office data | GraphQL Admin API (via apps) | GraphQL Admin API (via apps) | Syncing products, orders, customers |
| Custom business logic | Shopify Functions | Shopify Functions | Discounts, shipping/payment rules, validation |
| Events | Webhooks | Webhooks | Telling other systems what happened |
| Checkout | Shopify Checkout + Checkout UI extensions | Shopify Checkout + Checkout UI extensions | Payment and order completion |
Notice that the right-hand half of the table barely changes between the two columns. Going headless replaces the frontend. It doesn't free you from Shopify's backend or checkout. That's why I only recommend headless when the frontend genuinely needs it; the full comparison is in headless Shopify vs. Liquid themes.
The Storefront API vs. the Admin API
Developers and agencies mix these up, and the security implications are real:
- Storefront API: built for buyer-facing experiences. Basic access to products, cart and search can work without a token. Public access tokens are meant for browsers and are visible to buyers. Private tokens are for servers and must stay secret.
- Admin API: built for managing the store. It can read orders and customer data and change prices. Its credentials must never reach the browser.
Both are versioned. Shopify releases a new API version every quarter, and each stable version is supported for at least 12 months. Someone on your team needs to own upgrades.
Where frontend and backend problems usually hide
When I audit a store, these are the seams I check first:
- Third-party scripts on the frontend. Every app that injects JavaScript affects speed, especially INP (how quickly the page responds to taps). Remove what you don't use.
- Client-side rendering of critical content. If prices or product details only appear after JavaScript runs, speed and SEO both suffer. Render them in the HTML.
- Logic in the wrong layer. A discount rule enforced only in the browser can be bypassed. Business rules belong in the backend, which on Shopify usually means Functions.
- Integrations without reconciliation. Webhook-only syncs drift over time. Add scheduled reconciliation jobs.
- Outdated API versions. Integrations pinned to old versions break quietly when support ends.
- Editor-unfriendly JavaScript. Theme code that only initializes on page load breaks when merchants edit sections. Component-based code avoids this; see my web components tutorial.
FAQ
Is Shopify a frontend or a backend?
Both. Shopify runs the backend (catalog, orders, checkout, payments) and provides a frontend through themes. You can also replace the theme with your own headless frontend that uses Shopify's backend through the Storefront API.
Do I need a backend developer for a Shopify store?
Often not, at least to start. You need backend skills when you build custom apps, integrations with other systems, or Shopify Functions for custom logic.
What's the difference between the Storefront API and the Admin API?
The Storefront API powers shopper-facing experiences and has tokens that can be public. The Admin API manages store data, including orders and customers, and its credentials must stay on a server.
Does headless make my store faster?
Not automatically. A well-built theme can be very fast, and a poorly built headless app can be slow. Headless gives you control over the frontend, and it also makes you responsible for its performance and hosting.
Where should business rules like discounts live?
In the backend. On Shopify that means native discount settings or Shopify Functions, so the rule is enforced in cart and checkout, not just shown in the browser.
Next steps
Sketch your store as two columns, frontend and backend, and list every app, script and integration in the right place. The gaps and overlaps show up quickly, and so do the seams most likely to break. If you want help mapping or untangling your store's architecture, book a Shopify consultation.
Sources
- Shopify.dev: Theme architecture
- Shopify.dev: Storefront API
- Shopify.dev: Hydrogen
- Shopify.dev: Cart API reference (Ajax API)
- Shopify.dev: Section Rendering API
- Shopify.dev: REST Admin API (legacy)
- Shopify.dev changelog: New public apps must use GraphQL starting April 2025
- Shopify.dev: Webhooks
- Shopify.dev: Shopify Functions
- Shopify.dev changelog: Shopify Scripts will be deprecated on June 30, 2026
- Shopify.dev: API versioning
- Shopify Dawn theme source: assets/global.js
