repo_prompt.md

Tenemos un repo para un CMS De testimonios.

Nuestros usuarios son:

user / publico -> tiene acceso a la API publica sin autenticacion

editor / autenticado -> tiene acceso a la api de edicion admin / autenticado -> tiene acceso a la api de edicion y puede aprobar posts

organizacion: a esta puede pertenecer un user o admin. -> para fines practicos y el mvp solo tendremos una organizacion global

el post/entry

cada post/entrada tiene 2 estados: approved y draftcon sus respectivos enums.

abajo se muestran ejemplo de los contenidos que tiene cada entrada:

export interface EntryData { 
    id: string // UUID v4
    title: string;
    content?: string;
    mediaUrl?: string;
    mediaSource: MediaSource;
    summary?: string;

    date: Date; // anything for simplicity
    tags?: string[];
    author: string;
    status: EntryStatus;
}

siempre que un editor edite o cree un post, este pasara al estado de draft, solo el admin puede aprobarlo.

rutas:

• /[organization_name]/all -> lista con todos los entries (ssg o api) el filtrado es client side
• /[organization_name]/entry/[entry_name]/ (ssg) una ruta de documentacion de API en la medida de lo posible

podemos

rutas estaticas

home page, logins, about y docs

debemos tener un modulo en dev para probar de manera agil esto

Dashboard

puede ser una spa en /dashboard y alli tener un cliente que acceda a la misma API, evidentemente con distinto tipo de autenticacion o podriamos hacer /edit/ lo importante es mantener el minimalismo ya que aqui ssg no es necesario, podemos usar la api existente

esta misma vista puede cambiar un poco para cada rol.

API

autenticacion basica y minimalista con api key, cada una se asocia con su usuario y respectivos permisos.

cada ruta debe:

• estar separada por scope con ()
• tener validaciones para sus entradas.
• usar middleware o permisos respectivos para cada rol
• hacer uso correcto de los metodos HTTP, less is more, keep it simple stupid
• usar la siguiente interface de referencia para respuestas:

export interface serverResponse {
  status: number;
  message: string | null;
  data?: any;
}

• podemos saltarnos la paginacion y devolver la lista completa de entries para cada org
• debemos garantizar que no ocurran colisiones entre datos y slugs

SOLID

para agilizar el desarollo implementaremos el "black box method" separando todos los concerns en distiontos elementos: Db service, crud, API, SSG y editor.

queremos scripts y tests individualizados que eprmitan probar componentes o codigo de forma individualizada y conjunta.

QA & testing

queremos implemntar seeding y testing end to end.

contibuciones:

lee contribuiting.md y aplica principios solid, si algo se usa o se podria usar en un contexto global dfejalo asi, por el contrario si solo se usa en una ruta especifica sseparalo.

para los endpoints ten de referencia lo que ya esta implementado