search

SaraBee / MCGJ

A Flask web app for running collaborative playlist parties
27 stars 7 forks source link

Use Odesli to give the driver a link to their music service of choice for each song. #13

Open toph-allen opened 3 years ago

toph-allen commented 3 years ago

Like:

  1. Evan Conway: Moderat — Rusty Nails ↗ Apple Music

You'd get the links only if you're the driver. The driver gets a dropdown link to select their preferred music service. If Odesli can't find a link for that song on that service, they can just use the regular link like they do now.

Here's the Odesli API docs: ~https://github.com/songlink/docs/blob/master/api-v1-alpha.1.md~ https://www.notion.so/odesli/Public-API-d8093b1bb8874f8b85527d985c4f9e68

SaraBee commented 3 years ago

I spent a bit of time thinking about how we'd implement this... we don't want to make the requests while rendering the session page, because it would mean one API request per track on the page before the page would even load. We also probably don't want to add columns to the schema to hold the URLs the way we do with album art, because we want to stay flexible on which platforms we support. So, two ideas:

  1. We stick the URLs in the driver's session cookie. The page will load slowly if someone starts driving or switches their preferred platform when there are already a bunch of tracks in the session, and will continue to be slightly slower than non-driver when reloading after cueing a a track (since this API call will happen synchronously while rendering the page post-cue). ~I'm also not sure how big a session cookie can get in general / before starting to cause problems.~ lol okay 4kb is not big enough for this approach

  2. We finally get around to doing some ajax calls and stick the preferred platform links back in the DOM after the initial page load. To speed this up / cut back on eating up our rate limit with Odesli, we could ~combine this with the first approach~ set up server-side caching. This is likely to feel faster for the user (since the page renders and loads quickly) even if it takes the same amount of time for the links to show up. Figuring this out would also be useful for #7 and other natural-feeling UX.

toph-allen commented 3 years ago

This is a good point.

Perhaps we should only look the URLs up once per track, so this should happen… when a track's saved? But that'd make that slower too. It'd be cool if you could dispatch the Odesli lookup from Python asynchronously.