Files

Gabriel Radureau db09d0ace1 📝 docs(adr): homogenize all 23 ADR headers to canonical format

Audit 2026-05-02 (Tâche 6 Phase A) had identified 3 inconsistent
formats across the ADR corpus :
- F1 list bullets : `* Status:` / `* Date:` / `* Deciders:` (11 ADRs)
- F2 bold fields : `**Status:**` / `**Date:**` / `**Authors:**` (9 ADRs)
- F3 dedicated section : `## Status\n**Value** ✅` (5 ADRs)

Mixed metadata names (Authors / Deciders / Decision Date / Implementation
Date / Implementation Status / Last Updated) and decorative emojis on
status values made the corpus hard to scan or template against.

Canonical format adopted (see adr/README.md for full template) :
    # NN. Title

    **Status:** <Proposed|Accepted|Implemented|Partially Implemented|
                  Approved|Rejected|Deferred|Deprecated|Superseded by ADR-NNNN>
    **Date:** YYYY-MM-DD
    **Authors:** Name(s)
    [optional **Field:** ... lines]

    ## Context...

Transformations applied (via /tmp/homogenize-adrs.py) :
- F1 list bullets → bold fields
- F2 cleanup : `**Deciders:**` → `**Authors:**`, strip status emojis
- F3 sections : `## Status\n**Value** ✅` → `**Status:** Value`
- Strip decorative emojis from `**Status:**` and `**Implementation Status:**`
- Convert any `* Implementation Status:` / `* Last Updated:` /
  `* Decision Drivers:` / `* Decision Date:` to bold equivalents
- Date typo fix : `2024-04-XX` → `2026-04-XX` for ADRs 0018, 0019
  (already noted in PR #17 but here re-applied since branch starts
  from origin/main pre-PR17)
- Normalize multiple blank lines after header (max 1)

21 / 23 ADRs modified. 0010 and 0012 were already conform.
0011 and 0014 do not exist in the repo (cf. README index update).

Body content of each ADR is preserved unchanged.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-03 00:27:42 +02:00

2.1 KiB

Raw Blame History

Use Chi router for HTTP routing

Status: Accepted Authors: Gabriel Radureau, AI Agent Date: 2026-04-02

Context and Problem Statement

We needed to choose an HTTP router for the dance-lessons-coach web service that provides:

Good performance characteristics
Flexible routing capabilities
Middleware support
Active maintenance and community support
Compatibility with our interface-based design

Decision Drivers

Need for performant HTTP routing
Desire for clean, idiomatic Go API
Requirement for middleware support
Long-term maintainability
Good documentation and examples

Considered Options

Chi router - Lightweight, fast router with good middleware support
Gorilla Mux - Well-established but heavier
Gin - High performance but more opinionated
Standard library - Simple but limited features

Decision Outcome

Chosen option: "Chi router" because it provides excellent performance, clean API, good middleware support, and active maintenance while remaining lightweight and unopinionated.

Pros and Cons of the Options

Chi router

Good, because lightweight and fast
Good, because excellent middleware support
Good, because clean, idiomatic Go API
Good, because actively maintained
Good, because good documentation and examples
Bad, because slightly less feature-rich than some alternatives

Gorilla Mux

Good, because very mature and stable
Good, because feature-rich
Bad, because heavier and more complex
Bad, because less performant than Chi

Gin

Good, because extremely high performance
Good, because good ecosystem
Bad, because more opinionated framework
Bad, because different from standard library patterns

Standard library

Good, because no external dependencies
Good, because simple and familiar
Bad, because limited routing capabilities
Bad, because no built-in middleware support

2.1 KiB Raw Blame History