Admin 29a7fed6a5 Generalize YouTube-backed endpoints behind a source parameter
Removes the last YouTube-specific routes (/youtube/*) and merges them
into the general track/album/playlist endpoints, keyed by a `source`
string validated against TrackSource. This mirrors the earlier track
search merge for albums and playlist-track additions:

- GetAlbums now merges local albums with live YouTube Music search
  results, paginated via a youtubeContinuationToken, deduped against
  already-materialized ExternalAlbum rows.
- New GET /albums/external/{source}/{externalId} and
  GET /tracks/external/{source}/{externalId}/stream replace the
  YouTube-only equivalents.
- POST /playlists/{id}/tracks replaces the separate
  .../youtube-tracks endpoint, accepting an optional Source/ExternalId
  pair alongside TrackId.
- AlbumSearchItemResponse/AlbumsSearchResponse follow the same
  discriminated-union + trailing-HasNextPage-field pattern already
  used for track search, so HasNextPage stays a required field in the
  generated OpenAPI schema.
- Frontend routes renamed accordingly (/albums/youtube/[albumId] ->
  /albums/external/[source]/[externalId], etc.) with a single
  /api/thumbnail proxy replacing /api/youtube/thumbnail.

Musify.Api.Endpoints.YouTubeEndpoints and the standalone
SearchYouTubeAlbums query are removed as a result.
2026-09-10 15:03:36 +02:00

Musify

Music streaming platform: upload your own tracks (or import them from YouTube), process them asynchronously (audio transcoded to .m4a, thumbnails generated) and stream them without the bytes ever going through the API.

backend/      .NET 10 — Domain / Application / Infrastructure / Api / Worker / StreamingGateway / Tests
web-player/   SvelteKit 2 + Svelte 5 + Tailwind 4 web client
deploy/       Docker Compose stacks — self-contained, no wrapper scripts
docs/         What each piece does and why (in Spanish)
dotnet test backend/Musify.slnx   # backend/Tests/ — Docker running (Testcontainers: Postgres, SeaweedFS)

Run it

Development (Docker Desktop):

docker compose -f deploy/compose.yml -f deploy/compose.dev.yml up -d

Infrastructure plus stream-ticket keys, database migrations and Zitadel OIDC provisioning — all as one-shot jobs baked into the compose file. Apps run from the IDE by default; add --profile apps up -d --build as a second command to run them in Docker instead.

Production, on a server with a domain:

cp deploy/.env.prod.example deploy/.env.prod   # fill in the domain and secrets
docker compose --env-file deploy/.env.prod -f deploy/compose.yml -f deploy/compose.prod.yml up -d
docker compose --env-file deploy/.env.prod -f deploy/compose.yml -f deploy/compose.prod.yml --profile apps up -d --build

Idempotent — run the same commands again to deploy an update. See deploy/README.md for the details, the port map and the production prerequisites.

Components

Service Port (dev) Role
Musify.Api 5111 REST API, issues presigned upload URLs and stream tickets
Musify.StreamingGateway 8081 YARP proxy that validates the stream ticket and serves the audio
Musify.Worker — MassTransit consumers: transcoding, thumbnails, YouTube downloads
web-player 5173 / 3000 Web client (SvelteKit, server-side OIDC session)
Zitadel 8080 Identity (OIDC/OAuth2)
PostgreSQL / RabbitMQ / SeaweedFS / Jaeger 59000 / 5672 / 8333 / 16686 Metadata, messaging, object storage, traces

More in docs/: architecture, authentication, storage, streaming, media processing, development.

S
Description
No description provided
Readme
5.1 MiB
Languages
C# 73.1%
Svelte 12.1%
TypeScript 9%
Kotlin 4.1%
CSS 1.1%
Other 0.6%