jd five

Branching and Graphs

You have state — one object for the refund job.

You still choose the next step with nested ifs inside one long function. That works, but the path is hard to see.

This chapter gives the path a name: a graph.

Two new words

Word Plain meaning Refund example
Node (step) A named piece of work lookup, decide, refund, wait_human, done
Edge (arrow) “After this step, go there” After lookup → always decide

A branch is a special edge: “look at state, then pick which node is next.”

Nodes do work. Edges choose the path.
  start
    │
    ▼
  lookup ──────────► decide
                       │
              ┌────────┴────────┐
              ▼                 ▼
           refund           wait_human
              │                 │
              └────────┬────────┘
                       ▼
                     done

Same story as before. Now you can point at the fork.

Same refund, as a graph

Node What it does to state
lookup Fill amount_usd and item
decide Set size to SMALL or LARGE (model helps)
refund Set approved, reply, status: done
wait_human Set approved: not_yet, reply needs approval
done Stop
From Edge
lookup → decide Always
decide → refund If size is SMALL
decide → wait_human If size is LARGE
refund → done Always
wait_human → done Always (for now — pause/resume comes next)

The fork lives in the edge table, not hidden halfway through a 200-line loop.

How a tiny runner works

You do not need a big framework. The idea is small:

current = "lookup"
while current is not "done":
    run the node named current   (it updates state)
    current = next node from edges + state

That is a graph runner. LangGraph and friends are fancy versions of this idea. You are learning the idea first.

Worked path — large order

Start state: order_id=4412, empty amount.

  1. Node lookup → amount 900
  2. Edge → decide
  3. Node decide → size=LARGE
  4. Edge (branch) → wait_human
  5. Node wait_human → reply needs approval
  6. Edge → done

Printed path: lookup → decide → wait_human → done

Small order path: lookup → decide → refund → done

Two paths. One graph. State chooses the branch.

Why this beats if-soup

If-soup in one function Graph
Path hidden in nesting Path is a list of node names
Hard to test one step Test lookup alone
New rule = deeper if New rule = new node or new edge

When someone asks “what happens on a large refund?”, you show the diagram — not a scroll of conditionals.

What is next

The wait_human node still finishes the program today. Real life needs: save state, stop, human says yes, load state, continue. That is the next chapter.

Words to keep

Word Meaning
Node A named step that reads/writes state
Edge The rule for which node comes next
Branch An edge that picks next from state
Graph The set of nodes + edges for one workflow
Runner The small loop that walks the graph

See it in Code

The Code panel builds this refund graph by hand, runs it, and prints the path of node names plus the final state. Check the Example console.