57 lines
1.3 KiB
Markdown
57 lines
1.3 KiB
Markdown
|
# Haskell Dependency Order
|
||
|
|
|
||
|
|
This note covers `34-haskell-dependency-order/`, which computes a deployment order from service dependencies and rejects cycles.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 1. What the Planner Has to Do
|
||
|
|
|
||
|
|
For each requested service, the planner needs to:
|
||
|
|
|
||
|
|
- find its dependencies,
|
||
|
|
- visit those dependencies first,
|
||
|
|
- avoid emitting the same service twice, and
|
||
|
|
- reject cycles and unknown names.
|
||
|
|
|
||
|
|
That makes the example a good fit for a graph-style traversal, even though the code stays small and explicit.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 2. Why the Output Order Matters
|
||
|
|
|
||
|
|
The planner emits `DeploymentStep` values in dependency order.
|
||
|
|
|
||
|
|
That means infrastructure and foundational services appear before dependents such as `api`, `billing`, or `frontend`.
|
||
|
|
|
||
|
|
This is the important behavior the example demonstrates: ordering is part of correctness, not just presentation.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 3. Why the Cycle Check Is Separate
|
||
|
|
|
||
|
|
The example tracks both:
|
||
|
|
|
||
|
|
- services currently being visited, and
|
||
|
|
- services already resolved.
|
||
|
|
|
||
|
|
That distinction is what lets it detect `a -> b -> a` style cycles without falsely rejecting shared dependencies that are reached more than once.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## 4. Commands to Try
|
||
|
|
|
||
|
|
```bash
|
||
|
|
cd 34-haskell-dependency-order
|
||
|
|
|
||
|
|
nix develop
|
||
|
|
cabal run
|
||
|
|
cabal run -- frontend billing
|
||
|
|
cabal test
|
||
|
|
|
||
|
|
nix build
|
||
|
|
./result/bin/mini-dependency-order frontend billing
|
||
|
|
|
||
|
|
nix run . -- frontend billing
|
||
|
|
nix flake check
|
||
|
|
```
|