In the previous series of articles I built RockRecommender, a rock recommender that learns your taste and returns the next song you will probably like. Except it stops exactly there. It returns a band name, a song title and a songId. It does not play anything. There is no audio, no video, no screen.
That is exactly the gap RockPlayer fills. It is a new project, separate from RockRecommender, whose only job is to take the recommendation and actually put it to play in front of you.
What RockPlayer does
The flow is simple: first an onboarding, where you pick the bands you already like (the same cold start explained in article 1 of RockRecommender). After that, one song at a time already playing on screen, with like and dislike, and every piece of feedback goes back to RockRecommender, which uses it to refine the next recommendation.
Two projects, two repositories, two jobs
The series uses two separate repositories: RockPlayerApi (.NET, following the same Clean Architecture, the same Result pattern and the same DDD principles already used in RockRecommender) and RockPlayerWeb (Angular 22). The reason for keeping the two separate is simple: the browser never talks directly to RockRecommender or to the music provider chosen to play the tracks, everything goes through RockPlayerApi. This keeps any API key out of the code that runs in the browser, and centralizes the decision of which music provider to use in a single place.
One detail that keeps coming back: RockPlayer has no database
This is intentional. And it raises a natural question: if there is no database, how does RockPlayer avoid asking the music provider the same thing over and over? That question has an answer, and it appears in article 3 of this series.
How the series will unfold
First the theory: the adapter pattern, which isolates the music provider from the rest of the system, how RockPlayer avoids asking the music provider the same thing twice without needing a database, and what really changed in Angular 22. Then the practice: the RockPlayer API layer by layer, the YouTube adapter finding and playing the full song, and the Angular front-end, from onboarding to the screen where the song actually plays. The next article already starts with the first piece of theory: the adapter pattern.