Emit messages to server to execute logic on song end

[arangace]

Certain player events should trigger an emit message from the client to the server and cause the backend to execute certain logic.

• On song end
  1. Emit a "song end" message to the server with the currentSong object and a isLastSong boolean as the payload.
  2. Once the server receives the message for the first time, it deletes the song from the database and broadcasts a "FromAPI refetch" message to all connected clients in that same room.
  3. Once a client receives a "FromAPI refetch" message, the frontend will re-fetch the updated playlist from the backend and set the current song to the first item on the playlist, or to undefined if playlist is empty.
     • a timer can be added to delay the refetch and act as a buffer for clients that are behind on song progress, the countdown can be displayed for improved UX
  4. The app re-renders and updates the playlist display and the player starts playing the new currentSong if it exists

[nivekyee]

@arangace @sjun521 @Akunda-p

On song end, implementing extra logic on the server/database to only operate on the first "song end" message received is redundant and impossible.

To check whether a "song end" message is the first instance received:

1. A songEnded field will need to be defined and set in the database, which means a mongoose call will need to be made everytime a "song end" message is received in order to fetch the field, which is no quicker than attempting a mongoose call to delete a song and failing.
2. The first "song end" message triggers a deletion event on the backend, therefore no subsequent "song end" messages of the same song will be able to run properly with the song already being deleted.

The only way to reduce server load is to prevent clients from emitting a message to the server.

This brings me to think, instead of deleting the song from the backend on a socket listener,

• is it actually better to have the client make an axios delete call on song end, and the server then emitting a refetch message on a successful deletion in songs-dao.js?
• does this approach actually reduce server load?
• the side effects of this is that every song deletion will trigger an app re-render, maybe logic can be implemented to prevent the player from starting a new song playlist[0]=currentSong?