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!