Saving Data from an API to Rails Database

Max Rabin
4 min readSep 9, 2021

For my Final Project at Flatiron School I decided to make an app that allows a user to search for movies through an outside API, the OMDb API, a user should be able to save a specific movie to their own Watch List. This functionality requires saving a movie from the API to a Ruby on Rails back-end. Initially this seemed extremely difficult and tedious to do, however, like many things involving coding after a few Google Searches and Blogs read I was ready to implement it.

HOW THE DATA COMES THROUGH THE API

This state array holds the data that comes from the back-end, notice that the data that is stored has a Title, Year, imdbID, Type, and Poster all capitalized (we’ll get to why this is important later). This state is set every time the User makes a search.

This is the function responsible for running the fetch to the API based on the searchValue state. In this blog we won’t go in depth into how this searchValue state is set, but just know that searchValue is whatever the User enters into the search bar on the web page. The searchMovies function is placed in a useEffect hook which allows us to control how frequently we want to run this function. Notice we use the second parameter of the useEffect hook to have an array with the searchValue stored inside. This tells the program that we want to run the searchMovie function every time that the searchValue state is changed or updated. The reason for the if statement is to avoid the app from setting the movies state even if there is not a search. This would break the rest of the app being that we use this movies state to display all of the movies being searched for, wouldn’t make much sense if the movies state was being set to an empty array even if there wasn’t a search being made. As far as the filterResp variable, a flaw with the API I chose is that certain movies do not have a Poster available to display. This made for a sloppy looking UI (user interface), the user would be able to see that there is a movie but wouldn’t be able to tell which movie because the image would come back blank. This variable handles this for me by filtering out all of the movies whose Poster value is equal to “N/A”, and setting state equal to the filtered array rather than all of the movies.

HOW THE DATA IS DISPLAYED AND STORED

This is the code responsible for displaying all of the movies that are searched for. Starting from the top we are mapping through all of the movies, and for each movie we are creating an image container to hold the poster image as well as an clickable overlay which triggers the POST request seen below. Important to note that we are passing the individual instance of a movie up to the handleWatchLater prop, which happens to be the addWatchLater function.

As you can see we are using that instance of the movie to set the watchLater state as well as using it with the body of the config object. Starting from the top, we create a new variable newWatchLaterList, spreading through the current watchLater state and adding the specified instance of the movie to state. From there we set up a Config object to specify which type of request we want to make as well as the data that is sent to the backend. For this case we made a POST request to ‘/watch_laters’ which is the table responsible for holding all of a User’s watch later movies. As mentioned earlier the data that is received from the API comes back as Title, and Poster, capitalized. Since we can’t have capitalized columns for our tables in the back-end, I had to make a title column as well as a poster column both lowercase. In the body of the config object, I am setting the title column to be the value of the individual movie’s title, and the same process for the poster. The user_id comes from the User state that is set when a User logs in. When someone logs in their instance of the user’s table is store in State to be used elsewhere throughout the project.

CONCLUSION

This has been a very brief overview of how to store data retrieved from an external API to your own Ruby on Rails Database back-end. Not too bad right? I hope this blog was somewhat helpful to you, now it’s time for you to try! Thank you for reading, and I’ll see you in the next one!

--

--

Max Rabin

Full-time Software Engineer Student Flatiron School