WeVolunteer: How I built a CLI with Ruby and ActiveRecord
Have you ever been curious about what goes “under the hood” in an app?
I’ve always wondered about how all the gears clicked together in the back — unseen by the user. For the past three weeks at the Flatiron School, we’ve worked with Ruby, and this process has effectively satiated some of my former curiosity… so I wanted to share a bit of what I’ve learned so far.
In this post, I am going to walk through a basic CLI (command-line-interface) app I created last week in a pair programming exercise. In that process, I will also briefly discuss what Active Record is in relation to Ruby on Rails.
I’ll cover how the gears fit together, or in other words, how each model of the app flows into each other using Ruby on Rails, a backend programming language, and Active Record macros. Hopefully, this will shed some light onto what goes on in “backend” development, satiate that sense of curiosity, and encourage readers to explore more complex programming structures!
For starters… What is Active Record?
Active Record is the Object/Relational Mapping (ORM) layer supplied with Ruby on Rails. In other words, it’s a Ruby library of CRUD (Create, Read, Update, and Delete) mechanisms to help us store, retrieve, and manipulate data in databases without directly writing SQL code.
Now, I’m going to demonstrate how I used Active Record to build out a CLI app
We named the app WeVolunteer, where users interested in volunteering can create an account and view lists of organizations in need of volunteers. After entering the system, the user can browse the various tasks within different organizations, whether its fundraising, pro-bono consulting, or physical activities, and add that task to their own assignment list. Within the assignment list, the user can update/delete their schedule accordingly. With this gist in mind, let’s dive deeper into the code! 💪🏻
Using the chart above, imagine each model as a gear and visualize them spinning in conjunction with each other to power the app’s functions. We’re working with three primary models: volunteer, task, and organization, while assignment acts as the joiner model. A joiner model sits at the receiving end of the chicken-footed has many relationships and acts as a single source of truth (SST).
For example: a volunteer has many assignments, a task has many assignments, and an organization has many assignments through tasks. Simultaneously, assignment belongs to volunteer and task.
Grasping this network of model relationships sets the foundation for the rest of your code, which can be visualized as smaller gears / nuts and bolts. The phrases “has many”, “has many through” and “belongs to” are not quirky word choices of my own choosing, they are macros for Active Record. These keywords act as essential linking tools between each model.
Let’s take a look at the assignment model. 🧐 This is our joiner model so we can see that it has two “belongs to” macros tethering it to the volunteer and task models, enabling both volunteer and task access to each other’s methods and data.
This is the volunteer model’s macros..
Here’s an example of a method within the volunteer model that calls upon the assignment model to execute the function of “add assignment”.
Prior to using Active Record, setting up relationships in Ruby could be SO tedious, often consisting of interweaving relationships, where I’d often lose track of methods and variables. These were all components that led to a huge time sink. Thankfully, Active Record came in like windshield wipers on a rainy day. 😁
As you can see in the above task model example, calling upon the organization class is so incredibly simple and efficient through the use of a macro.
Why is this important?
Using macros really enabled me and my pair-programming partner to build out our idea into code. Without an understanding of model associations and Active Record tools, I don’t know how we would’ve coded a multiple model application. In the future, after learning more programming languages and tools during my time at the Flatiron School, I’d love to return to this project and take it beyond the command line and work with different application programming interfaces, or APIs, to bring in real-time data. It would make me so happy to see the app in use! So, until then… ☁️
…
Here is my WeVolunteer github link, if anyone wants to play around with the code 😄 https://github.com/stephaniezou1/WeVolunteer-CLI
Sources:
https://www.tutorialspoint.com/ruby-on-rails/rails-active-records.htm
https://guides.rubyonrails.org/active_record_basics.html
https://api.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html
