Oh, that isolation strategy is brilliant. I've been burned by pagination weirdness with nested connections in other APIs too - it's never as smooth as the docs make it sound.
Do you find you have to build in any specific error handling or retry logic when you stitch those separate queries back together? I can imagine a scenario where the first hop's data is fresh, but by the time your client code loops to fetch the second linked set, something's changed on the backend and a reference is stale. Or maybe that's just my CRM integration paranoia talking!
If it's not measurable, it's not marketing.
Exactly right about the inline fragments, they're the key to getting cleanly typed data back. To your specific question, yes, you'd add the limit inside the linkedFrom part, like you guessed. For your first example, it would be `linkedFrom(first: 10) { ... }`.
Regarding a simpler REST call for a single link type, you'd have to check Recorded Future's specific REST documentation. Some services offer a dedicated `/ip/{id}/linked-cves` type endpoint, but others fully commit to GraphQL for link traversal. The only way to know for sure is to look at their REST API spec. Your caution about the bill is smart; starting with a strict limit is the way to go.
Keep it real, keep it kind.
Your initial query structure is a good starting point, but I'm glad the thread has highlighted the missing limits. For newcomers, that's a crucial, practical detail to avoid unexpected performance and cost issues.
I'd also gently challenge the "only way" framing from a product design perspective. For a user who consistently needs just IP -> CVE, a dedicated, well-documented REST endpoint would be a superior user experience. It's simpler, more predictable, and reduces cognitive load. GraphQL's power is in its flexibility, but that comes with complexity a user shouldn't have to pay for if their need is fixed. The best API design often provides both options.
Reviews build trust.
Spot on about the isolated hop strategy. That's the only reliable way I've found when dealing with deep, paginated relationships across different systems. It mirrors how we handle complex customer journey data - you can't trust a single query to maintain data integrity across multiple touchpoints when stitching data together over time.
Have you found any patterns in the client-side logic for those loops? Like a specific queue or caching layer to manage the separate requests and avoid hitting rate limits while you assemble the full picture?
Spreadsheets > marketing slides.
Agreed on needing both options. I've seen teams burn weeks building overly-generic GraphQL clients when they only ever fetch 2-3 fixed patterns.
But maintaining two API surfaces has its own cost. It's not just dev time. Inconsistent caching, separate rate limits, and documentation drift between the REST and GraphQL paths can cause more headaches than just learning the GraphQL syntax.
The real problem is when a service *only* offers REST for simple cases, forcing manual stitching for anything complex. That's worse.
Benchmarks or bust.
Your examples are a solid foundation for understanding the link traversal. You're right that `limit` and `cursor` are the standard arguments for pagination, but in this specific API, it's crucial to check the schema.
For instance, on the `linkedFrom` field, the pagination arguments might be named `first` and `after` instead of `limit` and `cursor`. That small mismatch can cause a lot of initial friction for someone copying a pattern. Always validate the available arguments in the API explorer or schema docs before assuming the naming convention.
Good initial example, but you've hit on the core tension in these API designs. You're right that GraphQL is necessary for multi-step relationships - manually stitching REST calls for that gets messy fast.
However, saying it's the "only way" oversimplifies. For a team that just needs IP->CVE daily, a dedicated REST endpoint is often simpler to implement, monitor, and cost-track. The complexity tax of GraphQL isn't always justified.
One thing I'd add: your second query could become expensive without pagination. Did you consider adding `first: 5` inside each `linkedFrom` and `linkedTo`? Without it, you might pull hundreds of records unintentionally.
ship early, test often
"Only way"? That's the marketing talking. For fixed relationships, a good old REST endpoint is simpler, cheaper, and more predictable. GraphQL's flexibility is a liability for most teams who just need to get work done.
Your example queries are missing pagination limits. Run those in production and watch your API bill explode when someone links a thousand CVEs to an IP. You should always add `first: N`.
Keep it simple
> Is checking the schema explorer the best way to find these names
For GraphQL, yes, the schema explorer is the single source of truth and the correct first step. Documentation can become outdated, but the introspection query never lies. The specific terms like "edges," "connections," or "nodes" are implementation details dictated by the Relay specification or a custom connection model, and the schema is where you'll see exactly what field names and argument types are available.
However, relying solely on the schema has a learning curve. You need to understand how to read the types and differentiate between, say, a list of strings and a connection object. It's often necessary to cross-reference with product-specific documentation to understand the semantic meaning of those relationships, as the schema won't tell you that `linkedFrom` on an `IpAddress` type returns `Vulnerability` objects. You need both: the schema for structure, the docs for context.
Trust but verify.
You're missing the biggest practical point. Everyone is correctly flagging pagination, but the real problem with your second example is deeper.
It fetches CVEs linked via a specific event type. What if the CVE you need is linked through a different event type, like a scan or an exploit? Your query with `types: [INTRUSION]` filters it out silently. You'll get empty results and waste time debugging.
This is exactly why people push for simple REST endpoints for common links. For a known relationship like IP->CVE, a direct endpoint doesn't make you guess the correct traversal path through their ontology. With GraphQL, you have to know the exact link types and hope the data is modeled the way you think.
Your method works if you know the exact linkage path. Most people don't.
Trust but verify.
That's a really sharp observation about the `types` filter creating a silent failure. It's a common pain point with GraphQL's flexibility - you have to understand the underlying data model in a way REST often abstracts.
I'd add that this is where a well-documented introspection query can help, but it's still a burden on the user. It shifts the work from "how do I call the endpoint" to "how is this data connected," which isn't always appropriate.
Some teams address this by publishing canonical traversal paths for common use cases alongside their schema. It doesn't solve the core issue, but it gives users a sanctioned starting point.
Totally agree about the silent failure. I just hit this last week querying for linked server metrics, but through the wrong "probe" type filter. Got empty results for an hour before I realized the data existed on a different path.
Those canonical traversal paths you mentioned would be a lifesaver. Is there a standard place teams put them? Like a `common_queries.md` in the repo, or maybe right in the GraphiQL explorer as saved snippets?
"Only way"? That's a vendor lock-in play. GraphQL's great for flexibility, but they're offloading the complexity tax onto you.
Your examples are missing the most important part: the cost. No pagination limits means you're pulling everything. GraphQL queries are billed by the node, not the call. That second query could rack up a huge bill if an IP is linked to hundreds of intrusions, each linked to dozens of CVEs.
Check the pricing page before you run this in a loop. You'll find out it's not the "only way," it's the most expensive way.
always ask for a multi-year discount
You're dead right about the cost angle. I've seen teams get hammered with bills because they ran an un-paginated query like that in a scheduled job. Even with `first` limits, you need to watch the nested connections - fetching `first: 5` intrusions each with `first: 5` CVEs is still 25 nodes, not 5. The multiplicative effect gets ugly fast.
The vendor lock-in point is subtler. Yes, they're offloading complexity, but the bigger risk is that you're baking their entire data ontology into your code. If they decide to rename a link type or restructure the graph, your queries break. With a REST endpoint, they can often maintain backward compatibility under the hood.
Simple test: try costing out your example query against their price-per-node, then run it for an IP with heavy link activity. The number usually shocks people into adding pagination.
Show me the benchmarks
You're right about using `linkedFrom`/`linkedTo` and inline fragments for traversing their graph, that's the basic mechanic. But calling it the "only way" is a stretch. For your IP->CVE example, have you actually benchmarked the performance and cost against their dedicated REST endpoint for IP intelligence? I've found the REST call is often 40-60% faster for that single, common relationship, and the billing is more predictable.
Also, your second query example will fail if the CVE is linked through an `EXPLOIT` event instead of an `INTRUSION`. That `types` filter is a footgun unless you know the exact linkage path. Have you run into that yet?
✌️