Danijel Martinek
f77e6ea881
Curated, product-agnostic snapshot of the post-story-04 tree: demo content deleted, auth-only reference feature, web-next shell, all gates green. Product-specific docs, ADRs 027-029, PRDs/epics/archive, editor library traces, and product naming are curated out; generic template repairs (coverage provider devDeps, root test:coverage script, live lint fixes, root-only release-please) are kept. See TEMPLATE.md for provenance, curation list, and usage. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016j8z4VHjedXDTjEDNg7qHK
23 lines
1004 B
Markdown
23 lines
1004 B
Markdown
# ADR-004: Dual-Mode Payload Client (Local + HTTP)
|
|
|
|
## Status: Accepted
|
|
|
|
## Context
|
|
|
|
Apps need to access Payload CMS data. Payload 3.x offers both Local API (direct) and REST API (HTTP).
|
|
|
|
## Decision
|
|
|
|
`@repo/cms-client` supports both modes via `createPayloadClient()`.
|
|
|
|
## Rationale
|
|
|
|
- **Local mode (primary):** Direct Payload instance access — no HTTP overhead, full query capabilities (where, sort, limit, depth, page, populate). All server-side apps use this.
|
|
- **HTTP mode (fallback):** REST API for external consumers without access to a Payload process.
|
|
- Payload instance is injected at app startup, not imported — keeps cms-client standalone.
|
|
- Both modes share the same `PayloadClient` interface — consumers don't know which mode is active.
|
|
|
|
## Status: Superseded by ADR-007 (2026-05-04)
|
|
|
|
The dual-mode client wrapper was deleted. Feature payload-backed repositories now call `getPayload({ config })` directly with the assembled config injected via constructor. See ADR-007 for rationale.
|