Photo: free stock photography (Unsplash licence) — see imprint
The problem GraphQL actually solves
If you have many different clients — web, app, kiosk, partner — each needing a different slice of the same product, REST forces you into endpoint sprawl or fat payloads. GraphQL lets each client ask for exactly what it renders. That is a genuine win.
The problem it creates
A single innocent-looking query can nest six levels deep and detonate into 4,000 database calls. You now need query depth limits, complexity scoring and dataloaders — infrastructure that REST simply does not require.
Caching is the quiet dealbreaker
REST caches beautifully at the HTTP layer: a URL is a cache key, Varnish and CDNs understand it for free. GraphQL POSTs everything to one endpoint, so you build caching yourself. For a high-traffic catalogue, that alone often decides it.
Our default
REST for catalogue and checkout, where caching and simplicity win. GraphQL for internal dashboards and partner portals, where flexibility wins and traffic is predictable. Mixing both is completely normal and not a failure.
- Many clients, many shapes → GraphQL.
- High-traffic catalogue → REST, for the HTTP cache.
- GraphQL without depth limits is an outage waiting to happen.
We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.
Talk to an engineer