Rewrite calls to Spotify API to exist in browser

[stevenstetzler]

I'd like to rewrite the application to support Spotify library scraping only in the browser, without reliance on a server-side application.

I think this could be possible re-writing the backend code in JavaScript using Node.js and this package: https://github.com/thelinmichael/spotify-web-api-node (found at https://developer.spotify.com/documentation/web-api/libraries/). Code built with Node.js can be bundled into a browser compatible javascript file (e.g. replace existing static/js/main.js) using browserify (https://browserify.org/)

User authorization can be performed in the browser without exposing our API client secret:

• The Spotify OAuth doc support multiple authorization flows: https://developer.spotify.com/documentation/general/guides/authorization-guide/#authorization-flows
• "Authorization Code Flow with Proof Key for Code Exchange (PKCE)" allows us to access user resources, refresh our access on-demand, and doesn't require a client secret be exchanged with Spotify: https://developer.spotify.com/documentation/general/guides/authorization-guide/#authorization-code-flow-with-proof-key-for-code-exchange-pkce

User access/refresh tokens can be stored in the browser cookies like they currently are.

Previously scraped user data can be cached in the browser and accessed through JavaScript using (I believe) Window.localStorage: https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API. Although it looks like there are storage size limits of a ~5 MB that might make it tricky: https://stackoverflow.com/questions/2989284/what-is-the-max-size-of-localstorage-values

Bonuses of doing this would be:

• All code is client-side (in the browser), meaning we don't have to allocate or manage any computing resources to host the app (Heroku right now)...GitHub Pages would be enough for us
• JavaScript allows for asynchronous programming, meaning faster library scraping than we currently do

Cons of doing this:

• Scraping could take longer for users with slow internet connections. We do a lot of data thinning/preprocessing in Python before returning it to the user right now. I think we scrape ~10s of MB (up to 100 MB? that might be too big) to a smaller amount of ~10s of KB to ~1 MB.
• Unclear how complicated handling multiple web pages would be (currently we have index.html and viz.hmtl, and might add more?)... I have a hunch it would be do-able, but less clean that the current Flask app/another server-side solution.