GraphQL vs REST for a Marketing Data API, After Building Both

An internal argument about whether a new marketing data API should be REST or GraphQL had been going in circles for two weeks on opinion alone, so we built a prototype of the same API both ways — querying campaign performance, audience segments, and attribution data — and actually used both against the same three real frontend consumers. Neither side's pre-argument was fully right.

Where GraphQL actually won

The dashboard frontend needed different slices of campaign and audience data on four different screens, each with slightly different field requirements. In REST, that meant either building four bespoke endpoints or one chunky endpoint that over-fetched on three of the four screens. In GraphQL, one schema served all four screens with each one requesting exactly the fields it needed, and the frontend team genuinely built faster once the schema existed — no waiting on a new REST endpoint for every new screen variation.

GraphQL's real win wasn't flexibility in the abstract. It was that the frontend team stopped needing us in the loop for every new screen.

Where REST actually won

Caching was the clear loser for GraphQL. A REST endpoint's response can be cached cleanly at the CDN layer by URL. A GraphQL endpoint is a single POST to one URL with a query body, which standard HTTP caching can't key off of at all — we'd have needed a persisted-query setup or a custom caching layer just to get back what REST gave us for free. For the attribution data endpoint specifically, which got hit by a scheduled batch job hourly with the exact same query every time, REST's trivial CDN cacheability outperformed anything we built for GraphQL without real engineering effort.

• GraphQL won clearly for the interactive dashboard, where field requirements varied a lot across screens and over-fetching was the dominant cost.
• REST won clearly for the batch/scheduled consumer, where the query never varied and CDN caching mattered more than field flexibility.
• GraphQL's N+1 query risk was real and required deliberate dataloader-style batching on our resolvers — not something you get by default, contrary to some of the hype.
• REST's discoverability (just read the URL) won for internal debugging and ad hoc curl testing — nobody enjoys constructing a GraphQL query body by hand to sanity-check something at 11pm.

We shipped a hybrid: GraphQL for the interactive dashboard, REST for the handful of scheduled batch consumers. Neither camp in the original argument was fully right, because the argument was framed as 'which is better' when the real answer was 'which is better for this specific consumer's access pattern.' Building both, even as a throwaway prototype, settled in a week what two weeks of opinion-trading couldn't.