1.3 KiB
1.3 KiB
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
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