Melodía Playlist Service — Backend

Tabla de contenido

1. Introducción
2. Aclaración sobre la base de datos
3. Lo más desafiante
4. Pre-requisitos
5. Guía de testing
6. Variables de entorno
7. Uso en desarrollo
8. Docker compose
9. CI/CD GitHub Actions

---

Introducción

API REST en TypeScript + Fastify + Drizzle (SQLite) para gestionar canciones y playlists publicadas. Soporta CRUD de canciones, publicación automática de playlists, agregado de canciones con addedAt, y listados ordenados (playlists por publishedAt desc; canciones por addedAt desc). Incluye Docker, tests (Vitest) y RFC7807 para errores. La solución implementa un servicio de playlists minimalista pero “production-ready”: Fastify como servidor, Drizzle ORM con SQLite (archivo), validaciones con Zod, logging con pino, errores RFC7807, y pruebas con Vitest. Está containerizada y lista para correrse vía docker/docker compose.

Aclaración sobre la base de datos

Una decisión tal vez controversial fue mi elección de base de datos, utilizando el motor SQLite, por lo que la base de datos es una librería en vez de un servidor. Esto cambia algunos aspectos de la resolución del enunciado. Respondiendo el punto opcional 4, para el TP grupal esta elección puede resultar no óptima si se quiere presentar un MVP ya preparado para una carga escalable.

Lo más desafiante

• Alinear ordenamientos exactos (playlists por publishedAt desc y canciones por addedAt desc) para que coincidan con criterios de aceptación y pruebas E2E.
• Hacer que la migración SQLite funcione igual en local, CI y contenedor (copiando el SQL al dist y creando el directorio de datos).
• Mantener ESM + TypeScript sin fricciones (import paths, moduleResolution, dist limpio para Docker).

Pre-requisitos

• Node.js 20+
• npm 10+ (o tu manejador preferido; el proyecto usa npm ci)
• Docker 24+ (opcional, para contenedores)
• Docker Compose v2+ (opcional)

La base usa SQLite (archivo). No se requiere levantar un motor externo para desarrollo ni para CI.

Guía de testing

Este repo usa Vitest. Documentación oficial:
👉 https://vitest.dev/guide

npx vitest run --reporter=verbose

Variables de entorno

Archivo .env.example incluido:

• HOST (por defecto 0.0.0.0)
• PORT (por defecto 8080)
• ENVIRONMENT (testing, dev, prod)
• DATABASE_URL (para SQLite: file:./data/melodia.sqlite)

Se dejó ejemplos de configuración si se migrase a una base de datos con motor de servidor como Posgres

Uso en desarrollo

Correr local:

npm start

Docker compose

Punto opcional 5

Build + up

docker compose up --build -d

Ver logs

docker compose logs -f api

Apagar

docker compose down

CI/CD GitHub Actions

Punto opcional 6

Este repositorio incluye un flujo de CI/CD con GitHub Actions para automatizar la ejecución de tests y la construcción de la imagen Docker. Se ejecuta automáticamente en cada push o pull request hacia la rama main.

1. Node tests (Vitest)

   • Instala dependencias (npm ci).
   • Construye el proyecto (npm run build).
   • Ejecuta todos los tests (unitarios y uno end-to-end) usando Vitest.
   • Para la base de datos usa un archivo SQLite temporal (./data/ci.sqlite), por lo que no es necesario levantar un contenedor adicional.

2. Docker build

   • Solo se corre si los tests pasaron.
   • Construye la imagen Docker de la aplicación con el dockerfile incluido.
   • No la pushea (solo la valida). Para producción, se puede extender para hacer push al registry deseado (ej. Docker Hub o GitHub Container Registry).

3. Variables de entorno en CI

   • DATABASE_URL=file:./data/ci.sqlite → Usa un archivo SQLite descartable para las pruebas.
   • NODE_ENV=test → Indica modo test.
   • VITEST=true → Flag interno que puede usarse para condicionar el código a modo de testing.

4. Migración a producción

   • Para producción se recomienda cambiar la base de datos a una en un contenedor separado, como Posgres.
   • Se puede extender el workflow para hacer docker build y docker push hacia un registry, y desplegar automáticamente la imagen en un servidor o plataforma (ej. Fly.io, Railway, Kubernetes, etc).