“Come Fly(Drink) with me…”
I recently finished curating my very first fully working Ruby application using Sinatra & Active Record. I wanted to design an app that allowed users to keep track of their cocktail/drink recipes as well as view other user’s in the community. This was my second project as part of my coursework for Flatiron’s Full Stack Developer Program. I must say this was my “Ah-ha” moment within the program. After completing this project, I felt more confident in my Ruby skills, including: debugging, better understanding of classes and instances as well as how the internet works on the backend. My app followed the MVC pattern and utilized the CRUD operations in order to make a seamless user experience.
This project was a level up from my first CLI project because it allowed the user to keep track of their data in the database via the magic of Active Record which served as the ORM. Even though this project was more complicated, the gems, especially Corneal, along with a few macros made the overall experience smoother because it did a lot of the heavy lifting within the app. It also forced me to understand concepts better because I wanted to know what was actually occurring. I know as the program continues, processes will become more and more abstract and I don’t want to lose my way in process.
Following the installation of the Corneal gem, which provided a lot of the essential documentation, folders and useful gems. I obviously had to go in and make the necessary adjustments to best fit my app. Once my framework was prepped and ready, I started by creating my database tables and migration files. Those migration files inherited from Active Record in order to create those tables and establish the connection between each object. I had an User and Recipe table. The relationship included: User -< Recipes: Users have many recipes and a recipe belong to a User. These wonderful macros created those method attributes that would be useful after migration. The migration worked properly because I was given a schema file that displayed the created of those tables.
Now onto the controllers, which handled a lot of the logic between the database(model) and the user(views), which I will touch on later. To follow convention, I decided to create an application controller, which inherited from Sinatra and held all of my helper methods as wells various configurations that would be needed throughout this app. By inheriting from Sinatra, it gave my program access to the routes and HTTP Verbs (Get/Post/Put/Patch/Delete), among other things. My other two controllers included a user and recipe controller. Since the application controller was the high-level one, the other two inherited from it in order to make things seamless. This was done in case of any updates or changes that would affect all three and the simple fact that you can only run one file at a time. With that said, it was important to run the application controller within the config.ru folder and only use the other two. The configu.ru folder also housed the rake::override task that I’ll touch on later.
Since this app performs CRUD actions, it was important to include those within the user and recipe controllers. I utilized 7 restful routes in order to make the application functional. The Create route captured the data provided from the user via a Get request and created an instance of an user and recipe object in the database through a Post route. This was executed with the user filled out a form. The Read action was handled via a different Get route by locating the specific user or recipe based on the primary key that was assigned with the object was created and saved to the database. Out of all the actions, Update was the trickier route because it handled having to locate the object and making the necessary edits and then Putting/Patching that info to the database. I also had to include logic to ensure the protection of the user’s info as well as avoiding bad data from entering the database. This was executed via the method override function that I mentioned earlier. It gave the ability to make those changes via a post request since web pages do not recognized Put Patch and Delete request. Speaking of Delete, it used the same functionality as the update action but must simpler. After locating the object, I simply called destroy on it to remove the info from the database.
All the routes were associated to the view page in some capacity, whether they were rendered directly or via a redirect route that would eventually rendering the erb file. This ORM magic allowed data to be parse via ruby code and rendered for the user to view and understand. The View housed the index, show, edit and new pages. The forms that collected data from the user were housed within the new and edit files. These pages also contained html and css files for styling affect and in order to make the data persisted from the database readable. One thing I wish I had more time to work on would have been the customization of the app. I did learn a lot on the spot and look forward to implementing more on my next projects. Overall, this was a fun project to embark o
Top comments (0)