Fourth Project: Javascript
So tonight I’m wrapping up my Javascript project at the end of phase four in the Flatiron Software Engineering course. Over the last week of working on this, I’ve learned a ton (starting with “listen to Chris and don’t try to implement authentication in this project”). I decided to move away from making hockey applications for this one, and turned to one of my other hobbies: video games. The plan was to make an application that a user can make an account and select video games to add to their collection. From there, they can build tasks or events tied to loadouts(a collection of items / recipes that they’ll need). At the time of writing this, I’ve probably added about two thirds of the functionality I wanted for my stretch goals. That said, I think I’ve got everything set up properly to pass the project review, and should be able to finish the rest prior to the review. So lets get into it.
Starting out, I went a little overboard with my models again. Here’s a picture of what I’m working with so it’s easier to follow along:
So on the back end of the application, I’m utilizing the Twitch IGDB API to load information about video games. Similar to my Rails application, I’ve set up a FetcherServices module in app/services/fetcher_services.rb. The module has classes that will reach out to Twitch for a token(required to access the API), pull all games that met my search requirements (where involved_companies != null & rating_count > 250), then double back and pull all involved company and genre information for those games. I pulled a little bit more information than I actually ended up using during the course of writing the application, but it was pretty cool to see what all was available and was definitely good practice.
Once I had my test data up and running, I started working on setting up a User class and trying to figure out how to get authentication / authorization running properly. To be completely open about it, this was the single biggest setback I encountered, and took up most of my Tuesday night, as well as nearly all of Wednesday. Outside of documentation, I found two resources that were very helpful in working through it: this article, by Hristo Giorgiev at Pluralsight, and this article, by Sophie DeBenedetto at The Great Code Adventure.
The first article was helpful in setting up an initial configuration, but does not continue on to explain how to store JWTs on the client’s side in a secure manner (unfortunately I needed the whole thing spelled out). The second article picked up where the first left off and helped me to understand how to properly store the token, as well as better understand the full JWT lifecycle. Outside of that(in case anyone reading this may need to replicate it), to work in a development environment I had to serve the application from a Python simpleHTTPServer (python3 -m http.server now). Without serving the application with SSL enabled, CORs seems to require that the requesting domain be the same as the server — at least Google Chrome won’t save the httponly cookie. With that in the past, at the end of Wednesday I was able to log in and request games from my Rails API!
From here, things were mostly business as usual. Setting up the rest of the classes on the back end was relatively easy(at least after the last project), and outside of renaming some columns, I haven’t really moved the models around much. The most interesting / challenging thing on the front end was trying to implement classes that accurately depicted the classes on the back end. Whereas on the backend, all of the models use has_many / belongs_to, relationships on the front end are mostly stored in arrays, with everything seeming to populate from a tree-like structure. The user logs in and navigates to a their collection page(displaying UserGames). Say they follow the “loadouts” path, the UserGame they select fills it’s array of loadouts, a Loadout fills an array of Items. Coming from ActiveRecord-land, this way of thinking was a little counter-intuitive — I kept thinking something along the lines of there should be a join table here.
So with this week in the rear-view, I feel pretty happy with where I’m at. I pushed myself to work on a more complicated project than was necessary, and managed to learn quite a lot about authentication / authorization along the way. I still am concerned that I haven’t implemented a fool-proof setup on that end (I haven’t done anything related to CSRF tokens), but it’s certainly more secure than a Rails API out of the box.
Looking forward, I’m excited to start working with React — til next time!
