Design: where published posts live, and what a stored post contains
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- markdown, sqlite
- Ambito
- backend-api-design, cloud, databases
Direzione di ricerca
Read parent issue #16 and compare D1, R2, and KV against the listed blog and Worker requirements. Then write a decision record in docs/adr/ covering the store and layout, rendering choice, post shape, Worker reads, CMS writes and permissions, rejected options, rollback identification, and estimated read costs for post and list pages.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Part of #16.
Decide where published posts live and what a stored post contains, before any code. Compare D1, R2 and KV against what the blog needs: list by date and tag, fetch by slug, serve images and assets, read from a Worker with low latency, and stay cheap at blog scale.
Decide who renders: the CMS at publish time (store ready-to-serve output) or the Worker at request time (store Markdown and frontmatter). Decide how a published revision is identified (the existing published_hash) and how a rollback works.
Acceptance criteria
- A short decision record in
docs/adr/with the chosen store, the table or key layout, the rendering decision, and what was rejected and why. - The stored shape of a post is written out: slug, frontmatter fields, body (source and rendered if both), hash, published-at, and asset references.
- It lists exactly what the Worker needs to read and what the CMS needs to write, and the Cloudflare permissions each needs.
- Estimated read cost for a typical post page and a list page.
- Lingua principale
- HTML
- Stelle
- 0
- Fork
- 0
- Merge medio
- 1m
- PR unite (30g)
- 2
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di mrgnw/cfcms
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
G-nn-r/lg_heatpump#52 ·
-
area: core bug priority: high
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
griffinwork40/agent-afk#4872 ·
I maintainer di solito rispondono entro 1 giorno
-
fleet size/m
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
sipyourdrink-ltd/bernstein#7517 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
I maintainer di solito rispondono entro 1 giorno
-
BUG-MERGE-TO-HDR-RESULT-NAMEForse già presa Una pull request collegata a questa issue è aperta o già unita. Apertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
storytold/photocraft#14025 ·
I maintainer di solito rispondono entro 1 giorno