Tying Ruby on Rails to Spotify

Foreword: To C.H. Garza, my grandfather. The first engineer I ever met, and who helped inspire me to put hand to the world and shape it for the better.

Well if you know me, you’ll know this month has been particularly trying even in the middle of the pandemic. But basically this little post is about how I built an application in Rails that uses the RSpotify gem to gameify users’ Spotify playlists.

Well tons of people have written about building an application that uses OmniAuth. Many of them were fantastically useful while building Greatest Hits. However few authors, if any, really talk about the pitfalls and errors along the way. Of course a good scientist will tell you that much of knowledge is forged from documenting failures, which tend to occur in much greater volume than successes.

“It is, of course, extremely toxic, but that’s the least of the problem. It is hypergolic with every known fuel, and so rapidly hypergolic that no ignition delay has ever been measured. It is also hypergolic with such things as cloth, wood, and test engineers, not to mention asbestos, sand, and water-with which it reacts explosively. It can be kept in some of the ordinary structural metals-steel, copper, aluminium, etc.-because of the formation of a thin film of insoluble metal fluoride which protects the bulk of the metal, just as the invisible coat of oxide on aluminium keeps it from burning up in the atmosphere. If, however, this coat is melted or scrubbed off, and has no chance to reform, the operator is confronted with the problem of coping with a metal-fluorine fire. For dealing with this situation, I have always recommended a good pair of running shoes.”
― John Drury Clark, Ignition!: An informal history of liquid rocket propellants

Problem 1: ‘Ignition Delay' TheRails new Application Generator Fails

Normally any new application built in Rails begins with someone throwing down the immensely powerful rails new APP_NAME command. This kicks off a series of scripts that build out the boiler-plate code of whatever application is being built. In my case, building an app called ‘Greatest Hits’ it looked something like this $ rails new greatest-hits Rails then dutifully took off running through it’s checklist. Spitting out feedback in my Ubuntu terminal (ver. 2.x, running in Windows Subsystem for Linux) until it hit an odd error message.

Image 1: Where the Rails Generator Aborted

A deep dive into the Rails github repo, indicates this particular name error as shown in Image 1, reveals this is a fairly rare issue. One typically resolved by updating to the latest version of Rails. However, I already am using the latest version (at time of writing ver Rails 6.1.3.1, is still installed in root). After trying a few different variations of updating Node, Yarn, manually installing and updating WebPacker. Our instructor suggested I just try rolling back to an older version of rails. Sure enough, running with a version force command to use v.6.0.0 successfully built out the framework for my project. I must admit I’m still not quite sure what exactly is causing my issue with v6.1, but rolling back worked, problem solved.
Solution: Iteratively Rollback Rails versions till the generator works on local.

Coming back to the topic of computer security, the TCP Wrapper is an example of such a safety net. I wrote it when my systems were under attack by someone who appeared to walk through walls. -Wietse Venema

Problem 2: How exactly do we communicate with the Spotify API?

Image 2: How Information Passes Between User, Spotify API, and Application

Well thankfully, rather than having to compose all the methods necessary to communicate with the Spotify API, the RSpotify gem functions as a handy interface or ‘wrapper.’ As a component, the gem handles authenticating the it’s host application with the Spotify service for to the API backend, then on data queries from the application, provides a huge slew of data in the form of immense Ruby hashes. For example the resulting data for something as simple as a single music track, results in a many layered hash with nested hashes and arrays with hundreds of individual keys.
Thankfully with Ruby, installing RSpotify is simple:
We add this line to the application’s Gemfile:

gem 'rspotify'

And then execute:

$ bundle install

However, the Spotify API requires any request be prefaced with a pair of authentication keys. One is a public application ID key, which is a unique identifier key provided by the Spotify Dev console when you register an app for development. The second key is a secret numeric key used as part of a cryptographic hash that encodes your outgoing data queries. To provide these keys to the RSpotify gem, and the Spotify API without them being displayed publicly on the code repository, we’ll need to use a tool called a shim.

In this case we’re throwing down with Figaro, since it’s installation and configuration is fantastically simple. First we add the Figaro gem to our gem file. Then we run bundle install as normal. Once the gem ins installed, we run $bundle exec figaro install in the terminal. This will automatically create an annotated config/application.yml file and automatically adds it to the local .gitignore Now all we have to do is add theSpotify dev keys to this file in the following format.

spotify_id: "[YOUR ID KEY]"
spotify_secret: "[YOUR SECRET KEY]"

Boom! Now by saving the application.yml file, with the keys. Figaro will automatically shim those as environment variables when the RSpotify and Omniauth gems need them.

Solution 2: Speed up our development time by harnessing the power of an API wrapper gem