Retro Player.
Una biblioteca de música personal en el navegador: subes tus MP3 una vez y luego entras desde cualquier dispositivo para reproducirlos, renombrarlos o borrarlos. React adelante, una API en Express detrás, Google Drive para los archivos y PostgreSQL para los datos.
> Ver el código (se abre en una pestaña nueva)- Contexto
- Proyecto final del curso de Desarrollo Fullstack en CEI
- Mi rol
- En solitario, de la interfaz a la base de datos y el despliegue
- Duración
- Junio – julio 2024 (unas 4 semanas)
- Plataformas
- App web + API REST
El reto
El encargo para el proyecto final de mi curso Fullstack era una aplicación CRUD completa (crear, leer, actualizar, borrar) hecha con un framework front-end. Elegí React.
Quería construir algo que de verdad fuera a usar: mi propia biblioteca de música en el navegador. Subir mis MP3 una vez y luego entrar desde cualquier dispositivo para reproducirlos, renombrarlos o borrarlos.
Eso implicaba tres cosas que nunca había hecho: construir un reproductor de audio desde cero, trabajar con la API de Google Drive y encontrar un lugar gratuito para guardar archivos de audio pesados que una app web pudiera transmitir de vuelta.
Del botón de play a la base de datos
Paso 01 / 05
Empezar por el reproductor
El reproductor era la parte más arriesgada, así que lo construí primero, con unos pocos MP3 locales y sin backend. La reproducción corre sobre un único elemento de audio del navegador guardado en el estado de React, así que cambiar de pista cambia la fuente en lugar de crear un reproductor nuevo.
En una semana ya tenía play y pausa, anterior y siguiente, repetir y aleatorio, reproducción automática de la siguiente canción, un contador de tiempo y una barra de avance propia que muestra cuánto de la canción se ha reproducido y cuánto ya se descargó.
La tarjeta del reproductor: barra de avance con lo reproducido y lo cargado, y los cinco controles. Paso 02 / 05
Encontrar un hogar para el audio
Los archivos de audio son demasiado pesados para una base de datos gratuita, así que investigué dónde guardarlos y elegí Google Drive, al que accedo con una cuenta de servicio. En la primera subida de un usuario, la API crea una carpeta solo para esa persona y guarda ahí cada canción.
Los navegadores no pueden reproducir un archivo de Drive directamente desde otro sitio, así que agregué un pequeño endpoint proxy: el reproductor le pide una canción a mi API, y la API la transmite desde Drive con los encabezados correctos. La base de datos solo guarda ese enlace del proxy.
Paso 03 / 05
Construir la API
El backend es una API REST en Node.js y Express con 8 endpoints para el inicio de sesión, la lista de canciones, subir, editar, borrar y el proxy de audio. Las subidas llegan como un formulario multipart que maneja Multer en memoria, así que nada se escribe en el disco del servidor.
Antes de guardar, la API lee las etiquetas ID3 de la canción, así que el título y el artista se completan solos. Borrar una canción la elimina de Drive y de la base de datos a la vez, para que las dos nunca se desincronicen.
El viaje de una canción: del formulario de subida a Drive y la base de datos, y de vuelta al reproductor. Paso 04 / 05
Hacerla la biblioteca de alguien
En el front end, React Router separa la pantalla de inicio de sesión de la biblioteca, y un Context de React comparte quién inició sesión en toda la app. La API guarda una sesión por usuario, así cada persona solo carga sus propias canciones.
Cada fila de la biblioteca se puede reproducir con un clic, editar en el mismo lugar (el título y el artista se vuelven dos campos y un botón de guardar) o borrar. La lista se actualiza al instante, sin recargar la página.
Inicio de sesión: una tarjeta y nada más en pantalla. 
Editar una canción en su lugar: título y artista se vuelven campos, y el botón de editar pasa a guardar. Paso 05 / 05
Publicarla y mantenerla en línea
La API se desplegó en Render y se conectó por SSL a una base de datos PostgreSQL en la nube. Ambos repositorios están comentados de principio a fin y tienen un README que explica la instalación, las variables de entorno y cada endpoint.
Desde entonces la base de datos se mudó a Supabase, cuyo plan gratuito mantiene el proyecto en línea sin costo. Como la API habla PostgreSQL estándar, la mudanza solo requirió nuevos datos de conexión.
A mitad del proyecto, mi laptop murió. Todo estaba ya en GitHub, así que cloné los repositorios en otra máquina y seguí trabajando ese mismo día.
Si lo hiciera hoy
Retro Player fue mi primera app fullstack completa, y estoy orgullosa de ella. Mirándola con más experiencia, esto es lo primero que cambiaría:
- ContraseñasCifrarlas con bcrypt, o delegar el inicio de sesión a Supabase Auth, en lugar de compararlas tal como se guardan.
- Control de accesoRevisar la sesión en cada petición, para que cada usuario solo pueda leer o cambiar sus propias canciones.
- Almacenamiento de archivosMover el audio a Supabase Storage con enlaces firmados de corta duración, lo que elimina el proxy de Drive.
- Conexiones a la base de datosCompartir un solo pool de conexiones entre peticiones en lugar de abrir una conexión por consulta.
- ConfiguraciónLeer la dirección de la API y el secreto de sesión desde variables de entorno, no desde el código.
Nada de esto cambia lo que hace la app. Cambia qué tan segura sería con usuarios reales, que es la diferencia entre un proyecto de clase y un producto.
El resultado
Un producto fullstack que funciona, hecho en solitario en cuatro semanas: del botón de play hasta la base de datos, y todavía en línea hoy.
- 8Endpoints REST
- Inicio de sesión, biblioteca, subir, editar, borrar y el proxy de audio.
- 2Repositorios
- Un front end en React y una API en Express, ambos documentados.
- ~4Semanas
- De un repositorio vacío a una app desplegada.
- 0Líneas perdidas
- Mi laptop se dañó a mitad del proyecto; Git y GitHub lo tenían todo.
¿Necesitas una app web de principio a fin, de la base de datos al botón de play? Hablemos.
Humanimalidad