For a project at Flatiron school, I was asked to build a Ruby on Rails app using RESTful routes. Here’s the process I went through:
1 — General Outline
My previous project involved creating a database to keep track of movies a user could create and edit. I decided to continue this project, with some changes from the previous:
- Only an admin would be able to create and edit Movie models. Regular users would only be able to add or remove movies in their collection. This would prevent repetition in the Movie index page and would be more in line with how a modern website would do this.
- Because form_for and form_tag are soft-deprecated, I would use form_with in all of my forms.
- I would focus more on creating a DRY app and use partials and helpers whenever possible.
- I would allow users to sign in through Github using OmniAuth.
- Finally, and obviously, since this would use Rails, not just Sinatra, I would take advantage of any additional resources Rails provides in order to understand it better.
2 — Building the App
In my previous post, I discuss the difficulty of setting up a database, controllers, etc. Thanks to Rails, most of those issues are gone…but were replaced with new ones. I’ll go over the issues in further detail later, but OmniAuth was/is a pain, creating an admin/movies controller occasionally messed with my regular movie controller, and other problems constantly arose. I’m afraid to mention it, for hopes that otherwise it might be ignored, but my Github commits reveal that I constantly regretted any previous change and had no idea what I wanted. Without a better general outline, I constantly worried that my project didn’t show “enough” so I kept adding more and more. At first, I thought I would just meet the basic requirements in the spec.md file, but worried that obvious routes weren’t present and decided to add them in. In the end, I think it’s turned out pretty well, but I feel the route I took wouldn’t pass on larger projects or projects with a pre-existing codebase. Specifically, I want to get better at committing relevant files with the proper comments.
3 — Issues I struggled with
- OmniAuth — I followed the OmniAuth lab and lectures to set up OmniAuth, but kept on getting errors from Github or my server would crash. After hours and hours of troubleshooting, I created my own certificate and key and used those to secure my connection. Does Chrome hate my website because my certificate isn’t certified by a third-party (or something like that)? Yes. But does my website still work when config.force_ssl = true? Yes.
- SessionsController — In my Sinatra Project, I had my login/signin/signup routes defined in my User controller, but I decided that these routes are usually defined in SessionsController. Moving everything over wasn’t too difficult, but it’s always scary moving code because you don’t know if it will break.
- Admin/Movies, Movies, and UserMovies Controllers — I decided that only admin users could create or delete movies. I also decided to put all these routes in a different movie controller located within the admin folder. I also decided that, when a user adds or removes a movie from their list, it made sense to put that into a separate controller named UserMovies, because it was a UserMovie object being created or deleted. This lead to some struggles remembering what path to use and making sure they didn’t overlap.
- Github Commits — If there is one area I plan to focus on after this project it would be on becoming a better Github user. Though I committed early and often, I wished I had checked every corner case to make sure I liked the result and wasn’t going to change it soon after.
That’s what I learned during this project. Thanks for reading.