Webpack should provide better handling of Sass and hopefully wont have the same issues with @ngrx/store.

Maybe introduce a /api/me?action=logout function?

When I go to /auth/spotify/?redirect=http://localhost:8080 it redirects to spotify, but they print this message:

INVALID_CLIENT: Invalid redirect URI

I also tried /auth/spotify/?redirect=http://milkisevil.com but same error. The query string on the spotify page still shows a localhost url, so think it's using the referrer.

Perhaps spotify aren't fond of localhost? Not to worry if that's the case, as both Google and Twitter work well!! 👌 👌

I only found out about this today... how have I gotten by for so long without it?!?!?
http://nodemon.io

Router state should be held in the state tree. ngrx-store-router is worth investigating, not sure if it's fully functional yet.

Once this is complete, feature/redux can be merged back to master and we can proceed with the redux-style architecture.

And use existing integration tests to benchmark whether everything works.

We'll probably still want to call FunctionUtil.bindAllMethods(this); in the class constructor to avoid worrying about scope issues. Note: AFAIK, whilst fat arrow syntax does preserve class scope, it doesn't allow for inheritance as it's methods are not on the prototype (at least that's the case with Typescript's implementation).

Is it even possible to control the output volume of the server? At first glance, I can't see if this is possible via node-spotify. But it may be possible to control the native audio of the platform?

Do this once angular/angular#7485 is implemented.

This is a list of what we currently have in terms of api endpoints. Need to figure out if there's anything missing and what to use rest/websocket for.

rest

playlist

• /api/playlists (get)
• /api/playlists/:playlist_id (get, put, delete)
• 👎 /api/playlists/:playlist_id/play (get)
• /api/playlists/:playlist_id/tracks (get, post)
• /api/playlists/:playlist_id/tracks/:track_id/upvote

track

This call could be made internally whenever a track is added and the artwork data stored in the track model. Do we even need an api endpoint for 'track'?

• /api/track/:track_id/artwork

search

Search might be better off coming through the socket (from and to the individual client) as we'll probably have a 'results update as you type' thing going on and it will be faster. Prob harder to code like that though.

• /api/search/:terms (get)

users

The 'me' route could probably be merged into users as users/me. We could log user actions so we can have some nice stats later.

• /api/me (get)
• /api/users (get)

auth

• /auth/twitter?redirect={url} (get)
• /auth/google?redirect={url} (get)
• /auth/facebook?redirect={url} (get)
• /auth/spotify?redirect={url} (get)

websocket

client to server

• 'client:connect', (userId)
• 'client:pause'
• 'client:resume'

server to all clients

• 'track:start', (track)
• 'track:progress', (progress)
• 'user:connect', (connectedUsers)
• 'pause'
• 'resume'
• 'track:upvote', (data)
• 'playlist:end'

Looks like TrackController.getArtwork() will make a request to the server for adata:image/jpeg;base64 blob each time it needs artwork.

• 😡 Intense on a Raspberry Pi already playing back music. We need artwork for the currently playing track + thumbnail for every track in playlist.
• 😡 It may/may not implement caching in the node-spotify lib.
• 😡 It might be convenient using the node-spotify API, but might not suit other API implementations that would require us to make and cache HTTP requests ourselves.

I haven't checked the APIs to see if it would be possible, but can I suggest we either:

1. Store URL(s) to an artwork file on the Track. This is fetched when we first create the Track. If possible 2 images, one large and one smaller for thumbnails. Clients can make all requests.
   • 😡 Potential for dead links in DB if provider uses expiring thumbnail images, if that's the case we'd have to go for point 2...
2. Get the client to access the provider's API to get image URL based on the Track's provider and foreignId.
   • 😡 Requires provider's API to be implemented both client-side as well as server side. Uhh.

Would be great if you could add my usual Facebook account, thx!

Should progress events be limited to when a track is actually playing?

Sessions and cookies are a pain, because:

1. xhr.withCredentials must be used to send the cookie etc when cross domain
2. xhr.withCredentials requires that Access-Control-Allow-Origin is not a wildcard
3. Chrome doesn’t allow http://localhost to be used as Access-Control-Allow-Origin
   😭 😭 😭

A bit of a brain dump on how I've previously imagined this to work. This might not be the best way, it'd be good to discuss :)

The order of playlistTracks in the Playlist database should be continuously adjusted to reflect the desired order of tracks (ie. the currently playing track should be Playlist.tracks[0] and the next track should be Playlist.tracks[1]) .

Up vote

PlaylistController.upVoteTrack() triggers Playlist.upVoteTrack() which adds the upvote, sorts the tracks using playlistTrackSortCompare, then saves changes to the db. playlistTrackSortCompare is untested, but should order tracks by up vote then (if up votes are equal) by the date the track added to the playlist (ie. created date).

Potential issues:

1. When up voting a track, the closest it can get to the beginning of the tracks array is tracks[1] as tracks[0] is reserved for the "now playing" track.

Track end

The ended track should have its up votes cleared, then after applying playlistTrackSortCompare it should appear at tracks[tracks.length - 1]. I'm not sure playlistTrackSortCompare ensures this at the moment.

Next track for playback

As long as the Track Ended logic has run, this should be as simple as getting tracks[0]. PlaylistController.getNextTrackForPlayback() may need updating to reflect this approach.

Once a user up votes a track, they should be able to remove it by clicking the button again. Up Votes have been implemented server-side via handling the socket event EventTypeEnum.PLAYLIST_TRACK_UPVOTE in SocketController.

EventTypeEnum.PLAYLIST_TRACK_UPVOTE_DELETE should be created and will only delete an up vote already created by the logged in user.

Note: This is not a down vote :)

Because the API is now stateless, and sessions are turned on, a new session is created with each API response.

• Auth redirect URL to be added to .env
• Turn off sessions

@ianmcgregor Anything else relying on sessions?

The mocha integration tests currently adds data to the DB but doesn’t clean up after itself. It might be a good idea to set up a single DB just for running the tests and then clearing out that DB once tests are complete.

This is to prevent the tests from screwing up our own precious development (and in future, production) dummy data.