What the CRUD?
Understanding the four main operations that connect our Ruby models to our databases
Oh CRUD…another acronym.
At least that’s what I thought.
In my short time as a software engineer student (2 weeks to be exact), I have come across enough acronyms in my studies to create a small dictionary; SQL (Sequel Query Lange), OOP (Object-Oriented Programming), ORM (Object-Relational Mapping), API (Application Programming Interface) and so on. You get the idea. So when I was introduced to ANOTHER acronym, you can imagine me feeling a little bit like this:
I pushed on and read up on CRUD, as I did with the other concepts. However, this time, it felt a bit different. Rather than the feeling of learning to walk again, or reading through Readme’s that could’ve been in hieroglyphics instead, it felt like CRUD is actually a framework that is put together to HELP me understand a concept, in this case, understanding the mechanics of AR (Active Record — another one just for giggles).
Introduction: What the CRUD?
CRUD, which stands for Create, Read, Update, and Destroy, is essential for developers because it allows us to model the structures we build for our APIs. In other words, it connects our models with our APIs so they can speak to each other.
Let’s use an example. Imagine we are working with an API that stores a library of movies for a user to watch (OMDb API, for example). The movie database should have the following information:
- a unique ID number for each movie
- name of the movie
- genre of the movie
- movie synopsis
As a user, we should be able to access this library by creating an account (let’s say we’re using Netflix), browse the movie library by searching for the movie name or be presented with recommendations based on a specific genre, and add/remove movies from our watch list. If you read closely, each of our activities in the previous sentence falls under a CRUD category(Create, Read, Update, Destroy). Let’s examine each category more closely in the following sections.
Create, or C in CRUD, is our first letter in the acronym. Using our example above, these functions allow users to add new records so the data can persist in the database. It wouldn’t do anyone any good if an account was created, and for the user to come back the next day & found out it disappeared!
On the contrary, think about the movie library that we as users choose from on a rainy Thursday night. Imagine if no new movies were ever added since the inception of the database — there’s only so many times we can watch Harry get sorted into Gryffindor and not get a bit bored (or not for some, but we’ll save that topic for another time).
Let’s say we have a “Movie” model. We would create a migration that would define the schema of our database to add tables & columns. The migration would look something like this:
Here, we can see that we’re creating a create_table method, giving it the name of “movies”. Note that it’s convention to call your tables the pluralized version of your model, in this case it’s “Movie”.
The left side is the data type associated with their respective column name on the right side. With our table set up, we can now add new movies or add new columns to collect even more information about our movies!
Read, or R in CRUD, is our second letter in the acronym. These functions allow users to see the data. I think we can all agree that Netflix wouldn’t be as big as it is if users logged in to their account & just saw the word “Netflix”
Imagine creating lists, or categories of movies, for the user to see so they’re not overwhelmed with hundreds (or even thousands) of options when they log in. Perhaps we’re in the mood for a SciFi movie, or laugh hysterically to a romantic comedy, or even cry into a pillow during sad movies (no? just me? Give me your pillow then). It would be much more user-friendly for movies to be presented in a more organized fashion. And guess what? We already have that information persisted in our database because we have the genre of each movie!
Update, or U in CRUD, is our third letter in the acronym. Now this is where things can get a bit interesting!
These methods allow us to manipulate the data in our database. Let’s say we wanted to see which movies were watched the most frequent this past week — we can write a method for that! Our Top 10 movies can be listed for our users to see. And if our favorite movie fell outside of the Top 10? Well, we better start pressing “Play” on the Sorcerer’s Stone.
On the contrary, our users can also benefit from our update methods. The handy watch list is a great example, and helps our user keep track of the movies they’ve come across in their search that they’re interested in
Destroy, or D in CRUD, is our fourth and last letter in the acronym. These methods allow us to delete data in our database. Now why would we ever do that?
Imagine the movie database of Netflix — we have thousands of options for our users to enjoy, and while it’s great for those movies that are being watched frequently or even making the Top 10 list, there will certainly be movies that will be collecting dust on the shelf. Rather than continuously add new movies to our library and keeping all our existing movies in the database, there will be times when we’ll need to do some spring cleaning, won’t you agree?
With that said, it’s time to bring back “Friends” to Netflix, please.
And there you have it! We’ve examined each letter of CRUD and realized that it’s not so evil after all. CRUD contains the four main operations that a web service should know, and chances are that the method(s) you’re working with falls under one of these four categories.
Think about what other examples we can use to better our understanding of CRUD. Do you enjoy listening to music? Or do you love to travel? Build out your hypothetical database or think of some existing ones already that we can play with. As a brand new software engineer student myself, I’m sure I will!