Online edition for BLOGE
0.9.8-RC1· facts verified 2026-09-15 · 中文
Arc 1 Recap — Introductory (Chapters 1–4)
You now have the vocabulary and mental model to read a small BLOGE DAG and predict how its declared data dependencies move.
What You Learned
Chapter 1 — What BLOGE Is and Why It Exists gave you the three defining properties of BLOGE: workflows are visible (the graph shape is explicit), execution is dependency-driven (you declare edges, the engine decides order), and resilience is built in (retry, timeout, fallback are part of the model).
Chapter 2 — Your First Graph made the theory concrete. You built a graph,
ran it, inspected GraphResult, and saw that the engine — not you — decides
what can run in parallel.
Chapter 3 — Thinking in Dependencies sharpened your eye for dependency edges. You learned to read a DAG, spot unnecessary serialisation, and distinguish control dependencies from data dependencies.
Chapter 4 — Data That Flows completed the picture. You learned how data
enters via context, flows between nodes through input bindings, and exits
through node outputs. You practiced path expressions, safe navigation (?.),
null coalescing (??), transforms, and lambda input bindings.
What You Should Be Able to Do Now
- Describe BLOGE in one sentence without jargon.
- Draw the dependency graph of a small workflow on paper and predict its execution order.
- Write a simple
.blogefile with three or four nodes, explicit dependencies, and input bindings. - Read a
GraphResultand extract typed outputs safely. - Explain the difference between a transform and an operator node.
Common Mistakes at This Stage
| Mistake | Why It Happens | Fix |
|---|---|---|
Adding unnecessary depends_on edges | Confusing "this runs after that" with "this actually needs that node's data" | Ask: does the downstream node read the upstream output? If not, drop the edge. |
Ignoring findOutput in favor of getOutput | Assuming every node always completes | Use findOutput or getOutputOrDefault when the node could be skipped or fail. |
| Putting business logic in transforms | Transforms are projections without an Operator invocation or a separately scheduled node, but their expressions still consume compute | If the code has side effects or can fail, it belongs in an operator. |
Hard-coding values instead of using ctx.* | Copy-pasting from an example without parameterising | Move environment- or caller-specific values into the graph context. |
Key Vocabulary
| Term | Meaning |
|---|---|
| Graph | A directed acyclic graph of business steps with explicit data and control flow. |
| Node | One step in the graph, backed by an operator. |
| Operator | A typed function (I, GraphContext) → O that does the real work. |
| Dependency edge | A directed link that says "this node cannot start until that node finishes." |
| Input binding | An expression that resolves a node's input from context, upstream outputs, or literals. |
| Transform | A projection-only node — reshapes data but carries no scheduling overhead. |
| GraphResult | The immutable record returned after execution: success flag, outputs, statuses, timings. |
Try It: Remove a False Dependency
Draw breakfast as four nodes: boil water, toast bread, brew coffee, and serve. Add only the dependencies that are physically necessary. Then remove one edge and explain whether you gained safe parallelism or introduced a race.
Where to Go Next
Arc 2 teaches you to make decisions inside a graph (branches), handle failure (resilience), design clean operators, and write maintainable, reviewable DSL files. Start with Chapter 5 — Branches That Decide.