GraphQL 101 for Rubrik Security Cloud

Understanding how GraphQL really works in Rubrik Security Cloud (RSC) is a major shift for REST veterans. The move from REST to GraphQL within RSC represents a paradigm shift in how you retrieve data and trigger actions.

This article is a practical GraphQL 101, illustrated with real-world RSC examples and enriched by expert insights from my co-star in this series, Mike Preston. Mike is a Staff Technical Marketing Architect at Rubrik with over 25 years of experience spanning virtualization, storage, and infrastructure engineering. A long-time community advocate and author, he is driven by a core engineering pragmatism: "If I need to do something twice, it needs to be automated."

Whether you are a backup administrator, security engineer, or automation developer, this post gives you the mental model you need to work efficiently with the RSC API.

Rubrik Security Cloud is a global control plane designed to aggregate and correlate data across an extremely broad scope – multiple clusters, clouds, and diverse object types. In a traditional REST model, exposing this richness would require a massive number of endpoints and multiple API calls to assemble a single view.

GraphQL addresses these challenges by design:

• Single Endpoint: Rubrik exposes one API endpoint that represents the entire platform.
• Declarative Fetching: You have full client-side control over which fields and nested objects are retrieved.
• Strongly Typed Schema: The schema evolves without breaking existing clients, making integrations far less brittle.

GraphQL separates intent into two distinct categories, making the API's purpose clear:

Queries (Read-only)

Used to retrieve data from RSC. This is equivalent to combining multiple REST GET calls into a single, efficient request.

query {
  clusterConnection {
    nodes {
      id
      name
      version
    }
  }
}

Mutations (Actions and Changes)

Used to trigger operations or modify state (equivalent to POST, PATCH, PUT, or DELETE). 

As shown below, mutations take on much the same shape as queries

mutation takeVmSnapshot($id: String! $slaId: String) {
  vsphereOnDemandSnapshot(input: {id: $id config: {slaId: $slaId}}) {
    id
  }
}

Practitioner Tip:

"Having trouble finding the exact query or mutation name to accomplish a task? Leverage Chrome's DevTools to get a live view of all GraphQL queries and mutations being called as you navigate and perform the function manually through RSC."

If you take a look at the examples above, you might be wondering what all the text starting with a $ is. In GraphQL, anything prefixed with $ is a variable. It is simply a placeholder for a value you will supply when you actually run the query or mutation. This is how we pass data into GraphQL without hardcoding values directly into the operation.

Variables show up in two places. First, you declare them in the operation definition, right beside the query or mutation name, and you give them a type. Second, you reference them inline inside the query body wherever you need them. If a variable is not declared in the definition, GraphQL will not let you use it in the query.

When you execute the operation, you can send the values separately as a JSON variables object, alongside your query or mutation:

{
  "query": "mutation takeVmSnapshot($id: String!, $slaId: String) { vsphereOnDemandSnapshot(input: { id: $id, config: { slaId: $slaId } }) { id } }",
  "variables": {
    "id": "vm-123",
    "slaId": "Gold"
  }
}

Or, if you are just testing quickly, you can insert the values directly in the mutation itself instead of using variables:

mutation {
  vsphereOnDemandSnapshot(input: { id: "vm-123", config: { slaId: "Gold" } }) {
    id
  }
}

So the pattern is simple. Define your variables with types, use them inline where needed, and pass the actual values at runtime. Think of it like writing a function once, then calling it with different arguments whenever you need to.

One of the first things that surprises REST veterans in RSC is that queries rarely return a simple list. Instead, you receive a Connection. Following the Relay specification, this structure provides powerful guarantees around pagination and data consistency at scale.

The Anatomy of an RSC Query:

• The Connection: The container managing the full set of objects (e.g., clusterConnection).
• The Edges: The wrappers that associate an object with its position (cursor) in the list.
• The Node: The actual object you care about (a Cluster, VM, Snapshot, or Event).
• The Cursor: A unique, opaque pointer used to navigate the dataset reliably.

Mike’s Expert Insight: 

"If you understand the Connection → Node pattern, you can navigate 90% of the RSC schema without documentation. Once you recognize this pattern, exploring new parts of the API becomes significantly faster."

Pagination in GraphQL is cursor-based rather than offset-based. This is essential for the scale at which RSC operates, ensuring that results remain consistent even if the dataset changes during your query.

Example: Requesting the Next Page

query {
  clusterConnection(
    first: 10
    after: "YXJyYXljb25uZWN0aW9uOjEw" # The endCursor provided by the previous page
  ) {
    nodes {
      id
      name
} 
}
}

Practitioner Tip:

"Many queries within RSC also support a direct return of the nodes object, which removes the requirement of having to walk edges and paginate through the results."

The GraphQL Playground inside Rubrik Security Cloud is more than a testing environment—it is the authoritative documentation. Use it to search any object, inspect required arguments, and auto-complete queries live.

Practitioner Tip:

"If you are ever unsure how something works in RSC GraphQL, the Playground already knows the answer. Use it to validate your mutations safely before moving them into your automation framework. Proceed with caution since all queries will be performed against the production environment!"

Understanding these fundamentals allows you to reduce API calls dramatically and build a future-proof automation framework. Now that we have the mental model, we are ready to code.

Next week, we move to PHP execution:

• Authenticating to RSC.
• Sending your first production-ready query.
• Parsing and structuring results in PHP.