I recently released the source code of my recent side project Refrain and thought I’d write a little about the development process.
I decided to write Refrain on Node.js for no better reason than that a Node.js wrapper for the Spotify Web API showed up on Google before any others, and I thought it would make a change from writing Python for server-side code as I do at my job. I used the Express framework, which I’ve used once before for my dissertation project. It’s a great choice for these API mashup style projects. Saying that you don’t really notice it being there sounds like a bit of an underhanded compliment, but I mean that it’s not restrictive it all and yet I haven’t ever found myself having to re-implement parts of more comprehensive frameworks.
async/await notation in Node 8 was new to me, but once I’d refactored a couple of endpoints to use it I wound up going through the whole project and using it wherever appropriate. It’s one of those things that make you question “why wasn’t it always like this?”. The libraries I use at work don’t even support Promises consistently yet, which is frustrating when spotting a chain of callbacks that could easily be expressed in a human-readable way with the new syntax.
Earlier versions used a server-side implementation of local storage to store data since it made for rapid prototyping, but I later switched to using Mongoose, an object modelling library that uses MongoDB on the backend. Being able to move numerous utility functions for managing data into a few models made for a neater, more resilient code base so I’m glad that I tried it out. It’s the first time I’ve used MongoDB, or any other noSQL database. I found myself missing
JOIN operations, but not having to worry about table architecture or migrations helped keep development ticking along.
Playlist configuration in Slack is something that still needs a little work from a usability standpoint. The Spotify API doesn’t allow you to modify collaborative playlists, otherwise it would be a 10 minute job to write an app to hunt them down and systematically replace them with whatever you’d like. Unfortunately, this means that a given playlist can only be modified by the user who made it. I would like to make the link between Spotify users and playlists a little more obvious so that Slack users have a better idea of what they have permission to do at any given time. I don’t want to swamp them with information either, otherwise it’ll feel like a debugging exercise for them.
Without an “official” hosted version of the app, the barrier to entry is probably a bit too high for people without a little DevOps experience. As it stands, the code base will only work with one workspace, so it’s not really suitable for general hosting anyway. Tackling that will probably be my next task. I’m happy to be providing a FOSS alternative to a popular piece of software and I hope to make it equally accessible.