Codewerk.
Get a quote
Home/Blog/Node.js next to Shopware: the middleware pattern

Node.js next to Shopware: the middleware pattern

Not everything belongs in the shop. A small Node service between Shopware and your ERP solves problems a plugin never will.

Photo: free stock photography (Unsplash licence) — see imprint

Why a plugin is the wrong home for integration

ERP syncs are long-running, retry-heavy and failure-prone. Putting that inside a Shopware plugin ties your integration's uptime to your shop's deploy cycle, and a stuck job can take the storefront with it. A separate Node service fails independently — which is exactly what you want.

What the middleware owns

Field mapping, retries with backoff, deduplication, and the audit log of what was sent where and when. When sales asks why order 4711 never reached the ERP, you want one place to look — not three logs and a guess.

Queues, not cron

Cron jobs that poll every five minutes will either be too slow or hammer your ERP. Push events onto a queue (Redis, RabbitMQ) and let workers drain it. You get natural backpressure, retries and the ability to replay a bad day.

Keep it boring

This service touches money. TypeScript, explicit types on every payload, one framework, no clever abstractions. The most valuable property of integration code is that a new developer can read it in an hour.

Key takeaways
  • Integration failure should never take the shop down.
  • Queue + workers beat polling cron jobs.
  • One audit log, one place to look.

Frequently asked questions

A separate service, in almost every case. ERP syncs are long-running, retry-heavy and failure-prone. Inside a plugin, your integration's uptime is tied to your shop's deploy cycle, and a stuck job can take the storefront down with it. A Node service next to Shopware fails on its own — which is exactly what you want it to do.

Because a poller has only two settings: too slow, or hammering your ERP. Push events onto a queue and let workers drain it. You get backpressure when the ERP is having a bad day, retries with backoff instead of quietly lost work, and the ability to replay yesterday once you find out what was wrong. Cron gives you none of that.

By having exactly one place to look. The middleware should own the audit log: what was sent where, when, with which payload, and what came back. Without it you are correlating three log files and guessing. With it, the question takes a minute and sales gets a real answer instead of 'it failed somewhere, we think'.

Probably not. If it is one endpoint, runs in a second, and nobody loses money when it fails, a plugin is fine and a whole service is overhead you will have to operate. The pattern earns its keep when the sync is long-running, when it retries, when it must not take the shop down with it, or when someone will eventually ask what happened last Tuesday.

We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.

Talk to an engineer

// Keep reading

Related articles