Spotify Sessions: Origins, User Stories, and Technologies

As a music lover, I’m always interested in how people decide what music to listen to in groups. Whereas fifty years ago, we would listen to the records of whomever was hosting, now, everyone has their own devices that can manage endless music streaming applications. The process of picking a queue has become a bit more complicated and I’ve noticed three common situations can occur:

1. There is an aux cord war (or worse, a bluetooth war) and songs are constantly being interrupted making it almost impossible to enjoy anything that is being played.
2. While everyone may have a strong sense of musical taste, they are shy when it comes to sharing it with the public. No one wants the pressure of being the sole DJ, so one person obliges by default, but continuously bugs people for song suggestions.
3. People pass around a phone and democratically create a queue. Everyone gets to hear their favorite songs as well as discover new sounds.

The third is by far the most collaborative and preferable option — but what happens when the world is struck by a global pandemic and we can no longer gather in large numbers, let alone get close enough to pass around a germ-infested phone?

Sessions, a new Spotify beta feature, provides the solution to every DJ’s dilemma and allows CDC guideline-following individuals to co-create playlists at a distance.

While the feature seems like a natural solution to DJ-ing in the time of Corona, Spotify Sessions was brewing long before COVID-19 started to spread. Sessions was originally designed as a “party feature” to amp up traffic to the app. Rather than one person hogging DJ-ing rights and playing their favorite SoundCloud tracks all night, Session would offer a way for multiple users to log into their accounts and contribute to a communal queue.

You can imagine how this also creates an incentive for people without Spotify accounts to join. If you don’t have an account, you can’t get in on the collaboration. But how did Spotify rebrand their party feature into a pandemic feature?

Contrary to what you’d expect, people are listening to music less during quarantine. Folks generally listen to music on their commute to work, at the gym, at parties, or as background music while doing schoolwork. Now that most of these activities are obsolete, people are more likely to watch Netflix than sit at home listening to music.

Consequently, Spotify had to emulate the mission of other social distancing aids such as Google’s Hangouts and Netflix’s Teleparty. With a seamless transition, Sessions can now be seen as a way to connect individuals following lockdown orders and provide them with a way to stay connected through shared musical taste.

There are two main user stories for Spotify Sessions:

1. Local Group Session: A user navigates to the “Listening on…” icon in the bottom left corner of their streaming page. They click “Start Session” and other users scan a barcode to join the session. Up to 100 users in the same location can contribute to and edit a collaborative queue.
2. Remote Group Session: A user can start a session and send invitations to join through SMS, email, Whatsapp etc. Up to five users from anywhere in the world can join and participate in this remote session.

Whether you’re at a socially distanced outdoor gathering or on different sides of the country, Spotify Sessions eliminates the limitation of only being able to play music from one device and turns the passive act of listening to music into a participatory activity.

Now, I’ll delve into the technology that makes Spotify Sessions possible. The core capability in a feature like Sessions, is real-time bidirectional event-based communication. To understand what all these words mean, I will break down a simple user function.

Obviously, I was not able to find the actual code behind Sessions, so I searched around to see if anyone in the software engineering world had many anything similar. I discovered Playlistr, a collaborative music app by developers Connie Tran and John Herman that uses Socket.io and Spotify’s API to allow users to collaboratively design playlists in realtime. You can experience their deployed application here and checkout their Github repository here!

Socket.io creates a persistent bi-directional communication between client and server. In other words, Socket.io allows the frontend of your app to talk to the backend of your app, and vice versa. Event listeners track important changes in the database and emit notifications. Examples include when a user joins a session, when a user adds a track to the queue, or when a user skips a song.

To gain a better understanding of how sockets work, I will walk through an example of how Playlistr uses Socket.io to handle when a user adds a track to the collaborative queue. On the server, Connie and John set up an event listener that emits ‘new track’ when ‘add track’ is triggered:

socket.on('add track', ({ trackId, roomId, user }) => {
  socket.to(roomId).emit('new track', {
     trackId,
     message: `${user.display_name} added a track...`
  });
});

When a user adds a track to the queue in Playlistr, the method below is called, triggering the event listener above. In other words, the client-side React component is speaking to the server.

emitNewTrackToRoom = (roomId, trackId, user) => {
  socket.emit('add track', { trackId, roomId, user });
};

The final step exemplifies the magic of sockets and its bi-directionality. We have added a track on the frontend. This emits ‘add track’, an event listener on the backend. When the server receives ‘add track’, it emits ‘new track’, which is handled by a socket on the frontend.

socket.on('new track', ({ trackId, message }) => {
   this.addTrackToPlaybackQueue(this.state.accessToken, trackId);
   this.setRoomTracks(this.state.roomId);
   this.displayStatusMessage(message);
});

Rather than having to query the database with every change, sockets enable your client and server to be in constant conversation.

While I can’t say for sure that Spotify uses Socket.io in their Sessions feature, they are most likely relying on a technology that allows for realtime capabilities. Firebase, Pubnub, and SignalR are all alternatives to Socket.io and provide similar functionality.