37 lines
1.3 KiB
Markdown
37 lines
1.3 KiB
Markdown
# ADR-007: Drop the Dual-Mode CMS Client Wrapper
|
|
|
|
**Status:** Accepted
|
|
**Date:** 2026-05-04
|
|
|
|
## Context
|
|
|
|
ADR-004 introduced `@repo/cms-client` as a standalone wrapper supporting both Local API and HTTP modes. It was never used in production after Payload 3.x solidified its Local API as the primary pattern.
|
|
|
|
## Decision
|
|
|
|
Delete the wrapper. Feature payload-backed repositories call `getPayload({ config })` directly. The `config` is injected via constructor, avoiding hard coupling to `@repo/cms-core` at import time.
|
|
|
|
**Example:**
|
|
```typescript
|
|
export class PayloadArticlesRepository implements IArticlesRepository {
|
|
constructor(private config: Config) {}
|
|
|
|
async getById(id: string) {
|
|
const payload = await getPayload({ config: this.config });
|
|
return payload.findByID({ collection: "articles", id });
|
|
}
|
|
}
|
|
```
|
|
|
|
## Consequences
|
|
|
|
- One fewer abstraction layer — repositories work directly with Payload's typed API
|
|
- No "modes" — always use Local API from server code
|
|
- Package graph stays acyclic: feature packages never import `@repo/cms-client`
|
|
- `apps/cms` can directly boot Payload with the assembled config
|
|
|
|
## Alternatives Considered
|
|
|
|
- Keep the wrapper for "future-proofing": Payload 3.x is stable; wrapper was never activated in practice
|
|
- Add HTTP mode later if needed: Simple to implement when actually required
|