Flatiron School Rails Project: GameTracker 2.0

(Note: I'm moving my posts from my time at Flatiron School from my Github to this platform. This blog entry was first posted on February 20, 2020)

For my Rails project I thought it would be a good idea to rework the project I did for Sinatra and add more features that I never got around to adding. I was able to do that, however I lost some things along the way. This project really had me stressed out a number of times and there were moments where I honestly wanted to quit and never look at Rails again. Stepping away from the keyboard and coming back with a clear head usually helped me keep going, but I was still feeling doubtful about the state of my project.

My first big issue was that I was working with complex associations and I had to break the single source of truth rule a bit because I saw no other way. I wrestled with this for most of a day, trying to figure out how I could accomplish what I needed to without having to bring in another table association. Eventually I asked a Rails developer friend if this was okay and he told me that sometimes you just need to get the job done, and to play with it a bit, test it out, and if it's not breaking it should be ok. Maybe there is a better way do do what I wanted, but since I didn't know it I had to just get it done so I could keep working.

The problem: Games can be on multiple (have many) platforms, and platforms can have many games. Therefore a user can't just have a relationship directly with games; they need to have a relationship with games_platforms. That's how I did it for my Sinatra project and it was fine, until I added notes and play status (want to play, currently playing, completed) for this project. I didn't want these things to be associated with games_platforms because I thought it would be weird if a user owns a game on multiple platforms and has their notes scattered about the different platforms. I wanted a single game 'show' page that told the user which platforms they owned and displayed all their notes in one location. I decided I needed a users_games relationship with a status column, and the notes table could belong to it as well. I called these two tables owned_games and owned_games_platforms because it seemed easier than games_users and games_platforms_users.

Having multiple relationships between a game and user meant that any time a user deleted a game from their collection I had to make sure I deleted their relationship with all the games_platforms they owned for that game title. Once I figured out the logic for all of that the project started to come together.

As for what I lost, my previous project used the IGDB API to search for games and I really wanted that functionality here as well. I was not able to get it working and decided to scrap it since time was limited. It is something I will be adding back in the future as I continue to flesh out this project in my free time.

If you're interested in trying GameTracker out for yourself here is the Github repo.