alexatsu/tune-legacy

Purpose and deployment shape

Tune-legacy is a discontinued multi-source music application: users search, save, organize into albums/playlists, and stream music sourced through YouTube/Spotify (SoundCloud planned). It is a container-oriented microservice repository, coordinated locally by docker-compose.yaml, with CI/workflow automation under .github/workflows/main.yaml.

Primary user-facing application

The main product is a Next.js/TypeScript client with App Router pages, server-side API routes, authentication, and Prisma persistence.

• Web entry and global composition: client/src/app/layout.tsx, client/src/app/page.tsx, client/src/middleware.ts

• Auth boundary: client/src/app/api/auth/[...nextauth]/route.ts, client/src/app/_/providers/SessionProvider.tsx

• Music-area shell and shared player/navigation state: client/src/app/(music)/layout.tsx, client/src/app/_/providers/PlayerProvider.tsx, client/src/app/(music)/_/providers/StreamProvider.tsx

The UI is organized around music browsing/search, charts, albums, settings/themes, and an active player rather than a separate public API product.

Application API and persistence

Next.js route handlers form the client-facing backend boundary. They encapsulate database operations and service calls for songs, streaming, albums, charts, and preferences.

• Database access and schema evolution: client/src/app/api/_/services/db.ts, client/prisma/schema.prisma

• Song and stream endpoints: client/src/app/api/songs/search/route.ts, client/src/app/api/songs/stream/route.ts, client/src/app/api/songs/add/route.ts

• Album and theme mutations: client/src/app/api/albums/create/route.ts, client/src/app/api/albums/add-or-delete-song/route.ts, client/src/app/api/settings/themes/update-current-theme/route.ts

Prisma migrations indicate durable user, OAuth, music, album, and theme-related state. The exact database engine is not established by the supplied tree.

Music acquisition and streaming service

A Python service handles external music lookup, temporary listening/streaming, download/storage work, and audio models. Per the README, this layer uses yt-dlp to retrieve source metadata/audio and supplies media for client playback, with music ultimately wrapped in an iframe.

• Service entry and HTTP routing: music-service/src/main.py, music-service/src/routes/search.py

• Search, temporary stream, and storage pipeline: music-service/src/controllers/search/searchSongs.py, music-service/src/controllers/search/streamTemporal.py, music-service/src/controllers/search/saveAndStore.py

• Media acquisition/model boundary: music-service/src/utils/functions/downloadSong.py, music-service/src/models/audio.py

This service is the principal boundary between application-owned data and external content platforms.

Charts ingestion, processing, and presentation

Charts are a separate pipeline rather than being generated in the web app. A Node/TypeScript parser runs scheduled chart parsing, exposes/retrieves processed results, and can send them to backup; a Python charts service generates chart output consumed through the client’s charts API/UI.

• Parser startup, schedule, and chart controllers: parser-service/main.ts, parser-service/src/cron/parseCharts.ts, parser-service/src/routes/charts/controllers/retrieveProcessedCharts.ts

• Chart generation service: charts-service/main.py, charts-service/routes/charts.py, charts-service/controllers/charts/generateCharts.py

• Client integration: client/src/app/api/charts/get-all/route.ts, client/src/app/(music)/charts/page.tsx

Backup and external storage

A Bun/TypeScript backup service separates restoration and backup of charts/database data from request-serving components. Its Cloudinary utility identifies Cloudinary as an external storage integration.

• Backup service entry and operations: backup-service/src/main.ts, backup-service/src/modules/backupCharts.ts, backup-service/src/modules/backupDB.ts

• Restore/storage integration: backup-service/src/modules/restore.ts, backup-service/src/utils/cloudinary.ts

• Automation: .github/workflows/backup.yaml, .github/workflows/charts.yaml

Secondary desktop client

An early desktop implementation uses Wails: Go launches the native shell and a Vite/React frontend communicates through generated Wails bindings. It appears independent of the primary Next.js client and is not the main deployed product.

• Native entry points: desktop/main.go, desktop/app.go, desktop/wails.json

• Desktop frontend entry: desktop/frontend/src/main.tsx, desktop/frontend/src/App.tsx