Why headless commerce on Vue runs into integrations
Headless commerce removes the storefront's binding to the platform, but along with it go the built-in guarantees of data consistency. A Vue storefront reads the catalog, prices, and stock through an API — that is, from a second loop that has its own update timing. As soon as the loops diverge, the discrepancy is visible to the customer, not the developer.
Catalog integration looks simple as long as it concerns static fields. Dynamics break it: stock changes in real time, prices come from the promotions system, and some attributes are edited manually in the accounting system.
A price and stock desync leads to selling an out-of-stock item and a failure at the payment step — the most expensive class of failures in the funnel.
A separate problem is order intake. Refreshing the page or double-clicking the submit button sends two identical documents to the accounting system, and order duplicates are then handled manually: payments are reconciled, reversed, and the customer is given explanations.
From the outside it looks like "the site sometimes glitches"; in essence, it is a lack of idempotency at the junction of the storefront and backend.
Two more sources of failure are cache and discounts.
A category page from cache is served faster, but it shows an item withdrawn from sale or yesterday's price, and discount rules are calculated in two places at once, and when they diverge, the side that made the last mistake wins. We'll break down how this is closed — separately for each class of failure.
What separating the storefront frontend and backend gives
Separating the storefront and the accounting loop means that the interface layer lives separately from the logic of the catalog, prices, and orders.
The Vue storefront receives data through a software interface and assembles pages itself, while the commerce core is responsible for stock, discounts, and payment processing. Below are four effects that are visible in metrics already in the first months after migration.
Speed of releasing new pages and blocks
A new landing page, collection, or promo section is assembled from ready-made components and data, without changes to the store core. Releasing a page takes hours instead of weeks, and marketing does not wait in line for a general release.
The share of pages assembled from reusable components grows — each next one is made faster than the previous.
Independent releases of the storefront and the accounting loop — what changes in timelines and in the checkout failure rate
Updating the interface no longer requires stopping the accounting loop, and vice versa: changes to prices and stock are rolled out on their own cycle, without rebuilding the storefront.
Release timelines are reduced from weeks to days, and rolling back one part does not drag the other along.
The storefront is served from cache and holds peak traffic on static pages, so checkout does not go down along with the catalog. In real time, only the cart and payment go to the backend — a narrow section instead of the entire site.
Due to this, the failure rate at the checkout step decreases: the page does not lose responsiveness under load, and payment errors are localized and visible in the logs.
Integration modes: monolith, hybrid, decoupled storefront
| Option | When it fits | Limitations |
|---|---|---|
| Monolithic theme | Catalog up to several thousand SKUs, one sales channel, infrequent releases | Rendering and data are coupled: editing a block requires a rebuild, personalization runs into the template engine |
| Hybrid scheme | There is a working backend and admin panel, but Vue is needed on part of the routes | Two rendering stacks, routing and cache are coordinated manually |
| Decoupled storefront with a middleware layer | Multiple channels, frequent releases, SSR and edge cache needed | A separate data assembly service appears — its availability and schema versions must be operated |
Hybrid: storefront on top of an existing backend
Part of the routes is served by the former monolithic theme, the rest — by Nuxt with server-side rendering and edge cache. The catalog and cart remain in the current admin panel, so the transition goes page by page: first the catalog and product page, then checkout.
The price for this is two rendering systems and a shared cache that has to be invalidated on the same events.
Full frontend extraction with a middleware layer for data assembly
The middleware layer assembles the response for the storefront from the catalog, prices, warehouse, and content. The Vue frontend accesses a single contract and does not know how many services stand behind it — it is easier to cache by entity and release without backend changes.
The cost of the approach is a new service in operation, response schema versioning, and degradation rules when one of the sources is unavailable.
Implementation stages: from catalog analysis to storefront launch
We structure the order of work so that the catalog and order logic move to the headless storefront without downtime: first data, then exchange, and only then the customer-facing storefront. Below is the project route and acceptance points.
Order of work and approval points
- Catalog inventory — we collect product pages, categories, variants, stock, promo rules, and connections to the accounting system, and agree on the source of truth for price and availability.
- Data exchange schema — we describe which entities and at what frequency come to the storefront, what we cache, what we request on the fly, and how the storefront behaves when a source fails.
- Storefront and cache — we separate static and dynamic: catalog pages are assembled in advance, cart and availability are calculated on request, cache is reset by exchange events.
- Order scenario validation — we run search, variant selection, cart, promo, checkout, and return: in normal mode and when external services are unavailable.
- Load testing — we model peak waves on the catalog and checkout, look at response time and cache behavior during warm-up.
- Handover and launch — we switch the storefront to the production domain, and for the first days we operate with enhanced metric monitoring and a rollback plan.
Approval is at two points: after catalog inventory and before connecting the exchange to the production storefront.
What we do when the storefront is already running
We do not restart an existing storefront: we begin with an analysis of the exchange and find where data is lost and speed hits a limit. Then we move nodes one by one — catalog, cache, checkout — leaving the current interface live until the switch.
What remains in the project after handover: configurations and regulations
A project is considered delivered not when the storefront opens, but when your team can change and restore it without us.
Therefore, acceptance includes a fixed set of artifacts: in headless commerce projects with a Vue/Nuxt storefront, configuration lives in the repository, not in manual settings on the server.
- Storefront configurations: environments, server-side rendering and static generation, caching rules, routes, and redirects.
- Configuration of the middleware layer between the storefront and the commerce core: exchange routes, response transformation, failure behavior, load limits.
- Data flow schema: the path of product, stock, prices, cart, and order with cache points and places where data must be fresh.
- Access policies and integration keys: roles, token scopes, rotation procedure, secret storage rules.
- Catalog field descriptions: types, requiredness, localization, relationships between entities — new attributes are added without code changes.
- Update regulations: rollout procedure, mandatory checks before release, handling data schema changes.
- Rollback regulations: how to restore the previous version of the storefront and middleware layer, what data this does not affect, who makes the decision.
Documentation for your team
The materials are written for people who did not participate in development: where configurations are located, what is safe to change, and what breaks the contract with the commerce core.
Separately, there is a log of decisions made — why this particular exchange method was chosen and what limitations it imposes.
What we take with us and what remains with you
Everything related to the product remains with you: code, configurations, schemas, regulations, and the rights to them. With us — internal templates and general-purpose solutions; they are not included in the delivery. Access to your systems is revoked by act, and this is recorded in the handover.
Case study: transition to a decoupled storefront without a drop in orders
A store came to us with a catalog of several tens of thousands of SKUs: the storefront and product core lived in one monolith, so editing the catalog template affected warehouse and price logic.
A catalog page was assembled in an average of 4.2 seconds, noticeably longer during sale peaks, and the cart abandonment rate held at 68%.
Support requests about stock came in a stream: the customer saw an item as in stock, placed an order, and received a refusal after the fact. A new promotion could not be launched without a core release — marketing waited two to three days for development.
What turned out to be the bottleneck and how it was closed
The bottleneck was not rendering speed, but the coupling of layers.
The storefront was extracted according to the headless commerce scheme: a separate Vue application, with the Nuxt framework handling server rendering and routing; the catalog, stock, prices, and checkout remained in the product core and are served to the storefront through a thin data layer.
The cache was tagged with targeted invalidation when a product changes, the cart was moved to the storefront side — template edits no longer required a core release.
Metrics after the migration: catalog page assembly — 0.8 seconds instead of 4.2, cart abandonment rate — 51% versus 68%, stock-related requests decreased fourfold: the storefront reads stock from the product core, not from its own copy.
Marketing launches a promotion itself in 40 minutes. The switch was done by traffic share, with the ability to restore the previous storefront.
The gain came not from changing the engine itself, but from separating responsibilities: the storefront is responsible for speed and checkout, the core — for product, prices, and stock.
When a Vue storefront is more advantageous than a classic CMS theme
Separating the storefront from the content management system is worth it where the catalog is large, there are several sales channels, and the page structure changes often.
If a store lives in one channel, the assortment is stable, and improvements are rare and targeted — it is cheaper and faster to refine a classic theme.
Load on the catalog is the first criterion. A classic theme assembles the page on the server side on every request and each time accesses the database for price, availability, and filters.
A Vue storefront keeps the cache separate from the admin panel: the page is served from a prepared state, and the catalog stops being a bottleneck as traffic grows.
The speed of changes depends on code coupling. In a classic theme, markup, logic, and presentation lie inside the core, so editing a block affects templates and requires checking everything that depends on them.
The storefront evolves in separate releases: a new block is deployed independently of the admin panel and data, and rollback returns the previous version in minutes.
Maintenance cost is structured differently. A classic theme wins at the start, but each subsequent change request is more expensive: edits go into shared code and require regression testing.
A storefront is more expensive at the entry — you need to describe data contracts, set up build and deployment — but further changes land predictably and do not depend on updates of the management system.
A practical criterion: a decoupled storefront is justified when there are plans for new channels, frequent page changes, and catalog growth. A classic theme remains a reasonable choice if you need to speed up an existing site in a targeted way and not add moving parts.
Integrations, cache, and stock: technical doubts before the start
Before starting integrations with a Nuxt headless storefront, the same questions come up: how to keep the catalog and stock up to date, what to do with discounts in cache, and who is responsible for integrations after handover. Below are short answers for each, without generalities.
We run all scenarios before release on a test environment of the accounting system: divergence, load spike, external service unavailability.
How to avoid desync of catalog, prices, and stock?
The storefront does not read the accounting system directly, but its own copy of the data. Changes come in an event stream, the application applies them idempotently — a repeated event does not break the state.
Once a day we reconcile the full snapshot and fill in what was lost in the stream using discrepancies.
What about cache if promotions and discounts change every day?
We serve static sections and product pages from the caching layer for a long time, while personal prices, cart, and availability — we do not cache.
When a promotion starts, targeted invalidation goes out for the affected products and categories, so the new price appears on the storefront within a minute, not after a full warm-up.
Can we launch in parts rather than all at once?
Yes, and most often that is what we do. The first stage is the catalog and product pages, then cart and checkout, then the customer account and loyalty programs. Each stage is put on live traffic separately, and the old loop remains working until the result is confirmed.
Who is responsible for integrations after project handover?
We hand over the integration diagram, exchange contracts, change log, and instructions for typical failures — the customer's team can maintain the integrations itself.
If it is more convenient to hand them to us, we take on support: on-call duty, queue monitoring, updates when the accounting system's software interface changes.
What will the customer see if the accounting system is unavailable?
The storefront continues to work: the catalog and stock are served from a local snapshot. Orders are queued and go to the accounting system after connectivity is restored, while failed attempts go into a separate queue with an alert to the on-call person — no orders are lost.
Let's discuss the task: what to send for an estimate and work plan
The more precise the inputs, the fewer assumptions in the estimate. Below is the minimum set of materials that allows us to calculate the scope of work for a Vue/Nuxt storefront and avoid redoing the data schema in the middle of the project.
- Catalog description and requirements for it. How many products and categories, whether there are variants (size, color, bundle), section nesting, whether characteristic filters are needed, and how products get into collections. The route structure, pagination, and which requests go to the accounting system depend on this.
- Accounting system and data access. Which system manages products, stock, prices, and orders, whether it has software access or only exports, and how often stock is updated. A test environment is needed — estimation and debugging on production data become a risk.
- Current storefront scheme. Where the site is hosted, who serves the pages, how caching is arranged, which URLs are already indexed, and how redirects are configured. This determines the migration order without losing search positions.
- List of sales channels. Website, marketplaces, retail, app — it is important to understand whether the cart is unified and whether the warehouse is shared. This determines how to separate stock and where to check product availability.
- Rules for promotions, promo codes, and delivery. Types of discounts and conditions for their overlap, delivery cost calculation by zone, integration with delivery services and pickup points. Complex rules most often determine the labor intensity.
- Constraints on timelines and access. When launch is needed, who on your side grants access to systems and makes decisions on disputed points. If there are stages that must not be touched, flag them immediately.
- Current metrics, if the storefront is already running. Traffic, conversion, checkout failure rate, frequent errors in logs. This is the baseline for checking that after the work it became better, not just different.
Describe the task at this scope — we will come back with an estimate and a work plan broken down by stages, indicating what is needed from your team at each of them.
