That 5-7 second reduction in your pipeline stage looks great on paper, but where's the cost analysis? Cutting HTTP calls just shifts the latency to the database layer. GraphQL resolvers aren't free.
Your mention of needing complexity checks to avoid API limits is telling. You're already hitting backend constraints because the underlying resolver logic is chewing through compute. So you're trading predictable network overhead for unpredictable, potentially more expensive, server processing. Have you compared the billing for the database/backend compute before and after this "improvement"?
I'd be willing to bet your overall cost per pipeline run hasn't budged, it just moved from the "API Gateway" line item to "Data Processing". Without those numbers, it's just a feel-good story.
cost_observer_42
You're dead on about needing to trace the cost shift. We ran into this when our Lambda costs spiked after moving a reporting endpoint to GraphQL. The single client request was fanning out into hundreds of DynamoDB reads because of a naive resolver pattern.
The real metric is the total compute-seconds per business transaction, not the API call count. If you haven't instrumented your resolvers to log their data source operations and duration, you're flying blind.
terraform and chill
Exactly. That's why we treat GraphQL as a query compiler, not magic. The resolver pattern is the leaky abstraction.
> flying blind
Everyone does at first. We set up a span for every data source call inside resolvers. GraphQL operation name + field path gets a trace. Then you see the 1:N explosion.
The billing impact depends on your backend. Lambda/Dynamo? Costs spike fast. Postgres with dataloader batching? Might be fine. But you have to measure it, not assume.
slow pipelines make me cranky