Welcome back to my listening history tracking project! You are now reading the third entry, and I’ve achieved a great milestone - the listening history tracking actually works. You can query your listening history and it will be fed back to you in JSON, supporting specific queries like a start date, an end date, a limit on the number of entries, etc. (i actually ran out of examples.)

---

This JSON history endpoint does something that was very cool to implement; it gets the history entries, but obviously, those entries aren’t everything that a client needs to display them to the user. They consist merely of an entry ID, a track ID, and a date. The client would need to fetch the track details, then the album details, and then the artist details on its own, which would make for a lot of requests, considering that people usually listen to more than one track per day. So this would mean that, had the client not implemented some sort of caching, if you listened to, say, 25 tracks in a day and then queried your history, you would end up at a beautiful

n_entries * len(["track", "album", "artist"]) = 25 * 3 = 75

requests! Which is insane. This listening history endpoint reduces this number to 1. Yes, ONE request. This is done by directly including the necessary tracks, albums, and artists in the response, and the client can just iterate over the arrays of these resources and parse them into a hashmap keyed by their respective IDs. Pretty neat!

---

So had you listened to a track, like “Keep The Streets Empty For Me” by Fever Ray from their album Fever Ray, the (prettified) response from the endpoint would look like this:

 {
  "entries": [
    {
      "id": 3,
      "track_id": 8,
      "date": "2026-08-02T02:27:13.727572Z"
    }
  ],
  "tracks": [
    {
      "id": 8,
      "title": "Keep The Streets Empty For Me",
      "artist_id": 2,
      "album_id": 4,
      "genre": "Electronic"
    }
  ],
  "albums": [
    {
      "id": 4,
      "name": "Fever Ray",
      "artist_id": 2
    }
  ],
  "artist": [
    {
      "id": 2,
      "name": "Fever Ray"
    }
  ]
}

Looking at this, I’ve just realized that I probably need to make the genre column an array, since tracks usually exhibit properties of many different genres at once… that’s a problem for future me

---

Obviously I’ve improved the code a bit here and there, the Compose configuration now actually makes the backend wait for the database so there isn’t a race condition (which may have been there for a few weeks…), and the data schema has changed a bit so that it makes more sense.

---

There is now also a web app, but that is far from finished as it stands and so instead I’ve included a screenshot of the Firefox devtools I used to poke at my API and the successful response I finally got in the end.