Overview
Outpost should allow users to configure ID generation logic (UUID v4, UUID v7, NanoID) with optional prefixes per entity type.
Implementation
Both approaches use an idgen package with a singleton pattern - configure once at app startup via idgen.Configure(), then use idgen.Event() throughout the codebase.
Configuration: Two Approaches
Option 1: Config-Based (Recommended)
#530
id_gen:
type: "nanoid" # Global type for all entities
event_prefix: "evt" # Per-entity prefixes
Pros:
- ✅ Faster - strategy selected once at startup (no template parsing/execution)
- ✅ Simpler - easy to configure
Cons:
- ❌ Less flexible - can only do what we explicitly support
Option 2: Template-Based
#531
id_template:
event: "evt_{{uuidv4}}"
Pros:
- ✅ More flexible - custom prefix, suffix, and separator: "evt-{{uuidv7}}-prod", "{{nanoid}}.suffix"
Cons:
- ❌ Performance: ~2.7x slower (590ns overhead per ID) - negligible but measurable at scale
- ❌ User Experience: Less intuitive - requires learning template syntax, typos fail at runtime instead of config validation
Recommendation
Go with config-based unless we have a strong use case for template flexibility. It's simpler, faster, and easier to maintain. We can always add template support later if needed.
Overview
Outpost should allow users to configure ID generation logic (UUID v4, UUID v7, NanoID) with optional prefixes per entity type.
Implementation
Both approaches use an idgen package with a singleton pattern - configure once at app startup via idgen.Configure(), then use idgen.Event() throughout the codebase.
Configuration: Two Approaches
Option 1: Config-Based (Recommended)
#530
Pros:
Cons:
Option 2: Template-Based
#531
Pros:
Cons:
Recommendation
Go with config-based unless we have a strong use case for template flexibility. It's simpler, faster, and easier to maintain. We can always add template support later if needed.