Building From Scratch

Building a Rails app… From the beginning

This week at The Viking Code School we were tasked with building a CRUD Rails app from scratch using the Star Wars API. We were given free range on this task. Now, if I’m being honest here, building an web application using only the ideas in my head is a bit of a nightmare. I like being handed someone else’s ideas and trying to implement them. I like to help creatively. I knew this was going to stretch me.

The night we were first informed of the project I found myself racking my brain, how could I use the Star Wars API, which gives users information about the films in JSON to build something creative. For the longest time all I could come up with was building a compendium of the Star Wars universe. The next morning I woke up with the idea of using it to create your own Star Wars movie. A user would be given a selection of titles, characters and ships and use them to craft their own dream Star Wars movie.

The Building Commences

After our morning Scrum I set off on my project. First things first, setting up the bones of my app. I had created a Rails skeleton enough times to know the general idea of how I wanted my app structured. However, I had only used really basic databases, so when I began to think about how to structure the objects returned by the API in my database, things got a bit hairy.

Because the API returned a finite amount number of objects, I thought the best idea would be to store the information I needed in my database, requiring as few calls as possible and speeding up the application. This meant every character, ship, or film in my database could belong to multiple user created movies, and every user created movie could have multiples of these objects. Intellectually, I knew the solution, join tables, but in practice I had only used one-to-one and one-to-many relationships.

Many-to-Many

Fortunately, Rails makes creating join tables relatively simple. Creating a model with two attributes of type ‘references’ took care of a lot of the work. I found myself moving slowly at this point because of my fear of creating migrations in the wrong order…which despite my best efforts I ended up doing anyway. Building my models and database took up a good part of the day. However, even though my app wasn’t as strongly fleshed out as I dreamed of it being, this practice with databases was really good for me.

Releasing to Production

Our final task was to deploy our apps on Heroku. This is something I had done just a couple of times before, but never with a semi-complicated database. Issues struck when migrating my database from SQLite3, which we used in development, to Postgresql (PG) which is needed for production. Turns out PG is a bit more nit picky about its structure, and a few of my migrations failed after deployment. Eventually, most of the kinks were worked out, until my demo.

While demoing my app I realized that my destroy action, which worked with SQLite3, wasn’t working with PG on the backend. After looking through the logs, I realized it had to do with the way PG handles references compared to SQLite3. Unfortunately I wasn’t sure of the solution, fortunately, the rest of the application still functioned.

Idea to Deployment

Building a full CRUD app in a day that relied on an external API taught me a lot about expectations. A small syntax error can take 30–45 minutes to figure out, really slowing down your process. I think now I have an even stronger grasp of building a basic Rails app, and have been pushed to expand my creativity when it comes to thinking up my own app ideas.

If you’d like to build your own Star Wars movie, albeit with a primitive user interface, have a look here. If you’d like to see this applications source code, check it out on GitHub.