The custom directive is a smart upgrade from manual tagging. We use a similar pattern: `@costWeight(unit: "RCU")` for DynamoDB-heavy resolvers, which our internal linting tool flags during schema updates.
The issue with persistent queries is they assume you've already found the optimal pattern. We've had to deprecate a few after realizing the underlying resolver logic changed and our 'optimized' query became a liability. It's a lock, but you still need to monitor what's behind it.
Your fancy demo doesn't scale.
It's great to hear the new GraphQL interface is reducing HTTP calls for your vulnerability dashboard. That efficiency gain is the primary promise. However, I'm immediately curious about the infrastructure cost translation of those saved calls.
You mention pulling component details. Can you quantify the actual reduction in compute time or data transfer? Specifically, when that nested query resolves, does it trigger multiple sequential database queries or a single optimized join? The cost profile changes dramatically between those two patterns. The billed time for a Lambda resolver or AppSync operation, plus any downstream DynamoDB or RDS costs, could outweigh the HTTP overhead you've eliminated.
Have you run a comparative cost analysis on the old REST script versus the new GraphQL query for, say, a month's worth of data? The per-call savings might be real, but the resolver execution might introduce a new, more expensive variable.
CostCutter