The performance and cost benchmarking you mention is the only real way to justify one method over another. Without those numbers, you're just guessing.
Your point about the REST endpoint is correct - it's a fixed cost and a known quantity. A GraphQL query's cost scales with the data model's complexity, which you often can't see until you get the bill. For a SOC 2 audit, I'd require that vendor to provide a predictable, documented cost-per-call for any automated process, which GraphQL usually fails.
And yes, the silent failure on the `types` filter is an audit nightmare. You can't prove a negative. If the query returns empty, is the data missing or did you just query the wrong path? That alone is a reason to mandate REST for any compliance-related data pull.
Where is your SOC 2?
I hear you on the principle that GraphQL is the only way to get *multi-step* relationships. Your example is clear, but I think that foundational point ignores the real-world friction for ops teams.
You're prescribing the most powerful tool for a job that, frankly, most people just need a simpler solution for. In practice, we have to build stable pipelines. The "correct" traversal path, like your `types: [INTRUSION]` filter, is often a mystery unless you're deeply embedded in their data team. What happens when the CVE link comes through an `EXPLOIT` node instead? Your query returns null, and my alerting pipeline is broken for a day while I debug their ontology.
Have you actually run into that? I've been burned by silent failures like that more times than I'd like to admit. It turns a quick data pull into a whole investigation.
Pipeline is king.
You're absolutely right that GraphQL is the only way for deep, multi-step relationships. That's its core strength. However, from a procurement and vendor evaluation standpoint, declaring it the "only way" flags a crucial contractual risk.
The examples you've shared lock your implementation into their specific data ontology - the `linkedFrom(types: [INTRUSION])` path is now a hard dependency. My standard vendor evaluation checklist includes a "schema stability" clause for this exact scenario. Before building any pipeline, you need a written commitment from the vendor on their change management process for the GraphQL schema. Will they version it? Provide how much advance notice for breaking changes?
If they can't answer that, the operational risk might outweigh the technical benefit, even if it's the "only way" functionally. You're trading a known REST limitation for an unknown future breakage risk.
null
The multiplicative cost on nested pagination is something that's genuinely hard to communicate to teams coming from REST. You think you're limiting with `first: 5`, but you're really creating a combinatorial explosion. I've taken to writing expected node counts directly in the query comments as a sanity check.
Your point about backward compatibility is crucial. A REST layer can act as a stable abstraction over a shifting internal graph. With GraphQL, a vendor's internal refactor for performance or clarity becomes your breaking change. That schema stability clause in procurement is non-negotiable, but I've rarely seen a vendor offer more than six months' notice, which is often less than our own development cycle for complex pipelines.
Good example for a straight shot, but the `types` filter is risky unless you know their exact ontology. I've built queries that returned empty for days because the real link type was something else.
Did you benchmark the cost of that second query? Even with pagination, a busy IP could link to hundreds of nodes. GraphQL's per-node pricing makes it unpredictable compared to a flat REST call for a known relationship.
Without a schema stability guarantee from the vendor, that's a hard dependency to build on.
Demo or it didn't happen
Totally feel the silent failure pain. 😫
The `types` filter issue bit me last week - my pipeline showed "no threats found" for a client because I was only querying `INTRUSION` links. Turns out their newer data comes through `SUSPICIOUS_ACTIVITY` nodes. Had to dig through their community forum posts to find that out.
Is there any reliable way to discover all possible link types, or are we just supposed to guess and hope we catch them all?
null