Skip to content

Wiring & Routing

Wires are the fundamental building blocks of The Bridge. They define the exact paths data takes as it flows through your graph.

Every wire has a Target (left side) and a Source (right side).

There are two types of wires in The Bridge: Pull Wires and Constant Wires.

Pull wires resolve data dynamically at runtime. When GraphQL demands the target field, the engine traces the source, schedules any necessary tool calls, waits for the result, and drills into the response path.

# Dynamically pull the city name from the API's array response
o.city <- geo.items[0].name

Constant wires assign a fixed, hardcoded value.

o.country = "Germany"

When you are wiring deeply nested JSON objects (like a complex REST API request body), repeating long path prefixes over and over becomes tedious and difficult to read.

Path Scoping Blocks allow you to factor out the common prefix using curly braces { }.

Instead of writing this:

api.body.user.profile.id <- i.id
api.body.user.profile.name <- i.name
api.body.user.settings.theme = "dark"

You can write this:

api.body.user {
.profile {
.id <- i.id
.name <- i.name
}
.settings {
.theme = "dark"
}
}

The alias keyword allows you to declare a temporary, reusable node in your graph.

While it is incredibly useful for simply renaming a deeply nested path to make your code more readable, an alias is actually a fully functional evaluation node. The source expression inside an alias supports the exact same operators as a standard pull wire:

  • Safe Execution (?.) — swallows errors from the source
  • Logic (and/or, not) — boolean composition
  • Math & Comparison (+, -, *, /, ==, !=, >, <, >=, <=) — inline arithmetic and comparisons
  • Parentheses ((...)) — override operator precedence
  • Ternary (? :) — conditional value selection
  • Fallbacks (||, ??, catch) — falsy, nullish, and error boundaries

This makes alias the perfect tool for pre-sanitizing messy data or breaking complex fallback chains into readable, composable pieces:

# 1. Rename a deep, cumbersome path
alias api.response.data.metadata.address as addr
# 2. Pre-sanitize a fragile data lookup with a fallback
alias api.user?.nickname || "Guest" as displayName
# 3. Safely chain a primitive tool
alias riskyMathTool catch 0 as safeMathResult
# 4. Inline math/comparison expression
alias api.price * 1.2 as priceWithTax
alias api.score >= 80 as isPassing
# 5. Parenthesized expression
alias (api.a + api.b) * api.rate as total
# Route the sanitized local variables downstream!
o.zip <- addr.zipCode
o.name <- displayName
o.score <- safeMathResult
o.price <- priceWithTax
o.pass <- isPassing
o.total <- total

Because The Bridge uses a lazy, pull-based execution engine, a tool is never called unless a GraphQL output field actively demands its data.

But what if you want to trigger a side-effect, like sending an audit log, updating a cache, or firing an analytics event? The GraphQL client doesn’t explicitly ask for the log, so the engine would normally ignore the tool entirely.

The force statement eagerly schedules a tool for execution, intentionally bypassing the lazy evaluation rules.

bridge Query.search {
with searchApi as s
with std.audit as log
with input as i
with output as o
# 1. Wire the main API
s.q <- i.q
o.title <- s.title
# 2. Wire the side-effect
log.action = "user_search"
log.query <- i.q
# 3. Tell the engine it MUST run this tool
force log
}

By default, a bare force statement is critical. If the forced tool throws a network error, that error propagates up and breaks the entire GraphQL response, just like a standard tool failure.

If you want the side-effect to be fire-and-forget (where errors are safely caught and don’t break the user’s request), you can apply the Wire-Level Error Boundary (catch null):

# Fire-and-forget: If the logger fails, gracefully swallow the network error
force log catch null