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.

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

Talk to an engineer

// Keep reading

Related articles