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.
Frequently asked questions
REST for catalogue and checkout, where caching and simplicity win. GraphQL for internal dashboards and partner portals, where flexibility wins and traffic is predictable. The honest question is not which is better, but how many different clients need different slices of the same data. One client, one shape? REST — and stop reading the debate.
REST caches at the HTTP layer for free: a URL is a cache key, and Varnish, CDNs and browsers already understand it without you writing a line. GraphQL POSTs everything to one endpoint, so none of that applies and you build the caching yourself. For a high-traffic catalogue that single point often decides the question before any other argument gets made.
Yes, and it will not look dangerous to the person writing it. Nesting a few levels deep across relations can fan one innocent request out into thousands of database calls. That is why GraphQL needs depth limits, complexity scoring and dataloaders — infrastructure REST simply does not require. Ship GraphQL without them and you have shipped an outage on a timer.
No. REST for the public catalogue and GraphQL for the partner portal is completely normal and not an admission of failure. The two solve different problems. Standardising the whole company on one of them because it ought to be consistent is how you end up fighting the wrong tool in half your codebase.
We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.
Talk to an engineer