Quiet on the Set… ACTION! 🎬
Part 3: Front End and Back End Communication
This is the third and final installment of my blog trilogy detailing how RESTful routes enables the front end and the back end to communicate. The first installment, RESTful Routes, covers the standard guideline for creating URL addresses used in making fetch requests. The second, Rails Routes, covers how fetch requests from the front end are routed by Rails to the correct back end controller and action.
This installment, Quiet on the Set… ACTION!, will cover the final destination of these requests, the actions inside of the controllers. There are seven basic actions that correspond with the 7 basic RESTful routes. They include index, new, show, edit, create, destroy, and update.
These are the seven default action methods in Rails. However, you can override these actions by writing your own custom code inside of them to produce the specific responses you desire for your requests. You can even create additional actions to expand the functionality of your app.
Inside of each action are methods or code that will perform the requested action of the fetch request and then return the result or response to the front end for viewing in the browser.
INDEX
As indicated in my previous blog, Rails Routes, the index action will reveal all the songs in the database.
Inside of the index action, Song.all is used to assign all of the songs contained in the database song table to the @songs instance, then a copy of all the songs are returned to the front end.
SHOW
The show action is used to reveal details of a single song.
Song.find(params[:id]) is accessing all of the songs in the database and using the built-in find method to pull out a specific song by its unique id number. Params holds data that’s been input by a user (ex. clicking something or typing in data). In this song example, the data is input by the user selecting or clicking on a specific song. This captures the song’s unique id and sends it to the Rails backend which routes it to the song controller and show action. The unique id number stored in params is used by the find method to select the song with the matching id from the songs in the database and return a copy of it to the front end.
CREATE
The create action uses data (input by the user on the front end) to create a new song.
Rails has a security feature that allows developers to use a params method (in this example song_params) to restrict what data is allowed to pass into the database. So the data stored in params is verified in song_params then used to create a new song with the Rails built-in new method and assigns it to @song. If @song is saved, it’s added to the songs in the database and a copy of it is returned to the front end to verify the song was successfully created. If the song didn’t save, an error message is returned to the front end.
UPDATE
The update action is used to change the data about an existing song.
The unique song id stored in params is used to find the corresponding song in the database of songs, and then assigned to @song. The params data is verified by song_params and then used to change or update the data for that specific song. If it was successful the song is returned to the front end and if not, an error message is returned.
DESTROY
The destroy action deletes an existing song from the database table of songs.
The unique song id stored in params is used to find the corresponding song in the database songs table, and then assigned to @song. Then the Rails built-in destroy method is used to delete the song from the songs table. A copy of the deleted song is returned to the front end to verify it’s been deleted.
NOTE The new and edit actions are not included in the Rails controllers when Rails is used with a front end library like React. This is because the front end provides new and edit forms for the user to fill in and then the data is carried to the backend and routed to either the create action to create a new item or to the update action to change the data for an existing item. I’ve included the new and edit actions below to give a sample of what the code would look like.
NEW
The new action would provide a form that would be used to create a new song.
The user would fill in this form with data to create a new song.
EDIT
The edit action would provide a form, possibly populated with the current data of an existing song.
The unique id (of the song the user wants to edit) would be stored in params and used to find that song in the songs table and present a form to edit that specific song. The user would input new data or change the populated data for this existing song. This data input would be used to update the data for the existing song.
NOTE For more information, consult the Rails Guides https://guides.rubyonrails.org/routing.htmlI divided this topic into three installments, yet this blog trilogy only covers the basics. Use this trilogy to gain an overview of what’s happening in this process because some of the steps (ex. the controller receiving the request) are invisible to the developer. This trilogy can assist in understanding how data is being communicated between the front end and back end. Hopefully after reading this final installment, Quiet on the Set… ACTION!, you’re now ready to get this show rolling!
See what I did there?
TRILOGY: Front End and Back End Communication
RESTful Routes
Rails Routes
Quiet on the Set… ACTION!
