Skip to main content
The Pylon GraphQL API exposes a node root field that lets you fetch any object by its globally unique id. When your integration has an ID (from your app’s search (e.g. Cmd+X), a URL, a list, or a mutation), node(id) is a single way to load the full entity without choosing the right root query (loan, borrower, asset, etc.). That makes building a global “open by ID” and efficient polling much simpler. This follows the Global Object Identification pattern.

​
What the node query is

The root Query has a field (described in the schema as “Get an entity by ID”): 
node(id: ID!): Node!
  • You pass a single id (the same id value returned on any entity, e.g. from a previous query or mutation).
  • The server returns the object that has that ID. The return type is non-null (Node!); if the entity does not exist or you don’t have access, the API typically returns an error rather than null.
The return type Node is an interface (“An entity uniquely identified by its id field”) implemented by types such as Loan, Borrower, and Asset (and all asset subtypes, e.g. CheckingAccountAsset, GiftAsset). The concrete type is determined by the server based on the ID.

​
Example: loading by ID

When you have an id (e.g. from a list of loans or borrowers, from a mutation response, or from the URL), you can load that entity without choosing the right root query (loan, borrower, asset): 
query GetNode($id: ID!) {
  node(id: $id) {
    id
    ... on Loan {
      id
      currentStage
      loanAmount
    }
    ... on Borrower {
      id
      firstName
      lastName
    }
    ... on Asset {
      id
      amount
    }
  }
}
Use inline fragments (... on Loan, ... on Borrower, ... on Asset, etc.) to ask for fields that are specific to each type. The response will only populate the fragment that matches the actual type of the node. For asset subtypes (e.g. CheckingAccountAsset, GiftAsset), use ... on Asset to request common fields, or a fragment on the concrete type for type-specific fields.

​
What the node query is good for in Pylon

Use cases below are ordered by impact for typical Pylon integrations.
  • Powerful search (e.g. Cmd+X): You can build a global “open by ID” or quick-jump in your app: one search or “Open by ID” input where the user pastes or types a loan, borrower, or asset ID. Call node(id) with fragments for Loan, Borrower, and Asset; the response tells you what type it is and gives you the fields you need. One query, one input; no need to parse the ID or ask “Loan or Borrower?”. This is the highest-leverage use of the node query for daily workflow.
  • More efficient polling: When you poll for loan updates (stages, tasks, order-outs), you often have a list of IDs (e.g. deal.loans[].id or loans from a pipeline query). To refresh only what changed or to load detail for one item, use node(id) and request just the fields you need. One query shape for every entity type means less branching in code and, when refetching a single entity, a smaller payload than re-running a heavy loan or deal query. You can also poll a lightweight list query, then call node(id) only for the loans the user has open or that need updating.
  • Deep links and shareable URLs: Use URLs like /loan/abc123 so users can bookmark or share a loan. On load you have only the ID from the path. Call node(id) and use fragments to get the right fields; render the correct view from which fragment returns data. No need to encode entity type in the route.
  • List or pipeline to detail: Lists from Pylon (loans by deal or stage, borrowers, assets) return items with an id. When the user clicks a row, you have the ID. One node(id) call loads the full entity for that row; same query whether the row is a loan, borrower, or asset.
  • Refetch after a mutation: Mutations in the e2e flow return an id. To show the full entity or refresh the UI, call node(id) with the fields you need. Same pattern for every type you create or update.
  • Normalized caching: GraphQL clients (e.g. Apollo, Relay) that cache by id need one way to refetch any entity. The node query is that single entry point for all node types in Pylon, which fits normalized cache and refetch-by-id.

​
Behavior and limits

  • Stability: For a given id, the server returns the same logical object; if the same id appears in multiple places in a response, they refer to the same entity.
  • Missing or inaccessible objects: If the entity does not exist or you don’t have access, the API typically returns an error (the field is non-null Node!).
  • Fragments: Always request at least one type-specific fragment (e.g. ... on Loan { ... }) so you get useful fields; the shared id is always available on Node.
For the full specification and rationale, see Global Object Identification on GraphQL.org.