Broadcast playlist edits in real time using websockets #1212
Conversation
|
Hello @amCap1712! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found: There are currently no PEP 8 issues detected in this Pull Request. Cheers! 🍻 Comment last updated at 2021-02-10 11:35:12 UTC |
|
PR's cleaned up :) |
| handlePlaylistChange = (data: JSPFPlaylist): void => { | ||
| const newPlaylist = data; |
There was a problem hiding this comment.
| handlePlaylistChange = (data: JSPFPlaylist): void => { | |
| const newPlaylist = data; | |
| handlePlaylistChange = (newPlaylist: JSPFPlaylist): void => { |
|
I'll make a note to point out that we (alastair, rob and I) discussed a future improvement where the API would directly react when a playlist is modified and have an update sent, rather than require that It won't be for right now anyway, and I think the feature already works well. |
I too had thought about this. The way I thought we could get this to work is by setting up an update queue similar to what the TimescaleListenWriter does after successful inserts. It would be a bit more work, hence I decided to go with the current simpler implementation first. |
I completely agree with the approach of Incremental improvements. |
This concerns the websocket playlist update mechanism. We make sure we have set the state locally (after successful API calls) before calling emitPlaylistChanged as a callback, since it relies on that updated state.
|
@brainzbot retest this please |
We use a single WEBSOCKETS_SERVER_URL now
Edits made by the owner or collaborators on a playlist are sent instantly to all users who are have the playlist opened at that time. This is an initial attempt that just works.
Things like login authentication, using a queue and fetching playlist in the server itself instead of sending multiple requests from the client so on can be explored and included if needed.
This PR also contains removing the follow server part. I needed that for easy local testing but for merging that can probably be split into a different PR. I also removed the UNIQUE_EXCHANGE queue from
timescale_writer.py, as I was getting some errors. I think that was only being used by the follow server. I can try to explore that further if it is required.Tasks left