Design: where published posts live, and what a stored post contains
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- markdown, sqlite
- Área
- backend-api-design, cloud, databases
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Lenguaje dominante
- HTML
- Estrellas
- 0
- Forks
- 0
- Merge medio
- 1 min
- PR fusionados (30 d)
- 2
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de mrgnw/cfcms
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 45/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 45/100
Todos los issues de mrgnw/cfcms
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
OHDSI/Data2Evidence#3693 ·
Los mantenedores suelen responder en 3 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Project-N-E-K-O/N.E.K.O#3725 ·
Los mantenedores suelen responder en 1 día
-
[Bug] Sending a Telegram message chain twice duplicates mentionsPosiblemente ocupada @123XieC la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
AstrBotDevs/AstrBot#11125 ·
Los mantenedores suelen responder en 1 día
-
backend bug priority: high
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
nooriegarg/ContribIQ#73 ·
Los mantenedores suelen responder en 1 día
-
backend enhancement
Dificultad 2/5 Medio día Aptitud para principiantes 70/100
damodharg6/payledger#16 ·