Street Eats: A Rails Web App for Browsing Food Trucks
One of my favorite inventions of the last decade is the food truck. Okay, I’m sure they were are around before, but their gain in popularity in the last ten years is undeniable. You can visit almost any city and you’ll find a gourmet grilled cheese truck parked outside of a busy office building, a tamale truck posted up in front of a brewery, or a wood fired pizza truck at a private wedding. Food trucks are everywhere. In Knoxville, TN, where I live, there are tons of amazing food trucks to choose from. Yelp search results returns 104 trucks in Knoxville alone. Wow, that’s a lot of burgers and tacos.
One thing I hate, and I’m sure I’m not the only one, is the lack of an efficient way to figure out the schedule. In Knoxville, some trucks post their weekly schedules on their Instagram, Facebook, or website. That’s three different websites and platforms I have to check just to find Captain Muchachos! So I decided to build a simple web application to make it easier to find my beloved Korean beef tacos.
Behold, Street Eats
I built Street Eats as one of my portfolio projects for our Rails module at The Flatiron School. For this blog post I want to give you a quick tour of the app and my design process. To start, I mapped out the flow of the application, what models I’d need, and their associations. I used Draw.io for this.
This step really helps me to conceptualize and get my bearings before I jump right in and start writing code. It acts as a road map and helps give me a place to start. I decided I would need User, Food Truck, Reviews, and Favorites models, and their corresponding controllers. A user should be able to log in, view an index of all food trucks, review a food truck, search by cuisine, and see all their reviews.
Seed the Database and Create Migrations
For this app, I decided to manually seed my database with the most popular food trucks in Knoxville, rather than use the Yelp API. I did this for a couple of reasons. There’s a bunch of food trucks on Yelp that aren’t active and I wanted my app to provide some specific information I had to track down manually, like the link to their schedules. Once I had my top 20 food trucks in my seeds file and the information I wanted for each, I moved on to my migrations. I created tables for food trucks, reviews, and users. Once I generated those tables I ran the migrations and seeded the database.
Next I moved on to generating my models. I created the User model and defined it’s associations. A user has many reviews and has many food trucks through reviews. I also added validations for username and email. The food truck model has many reviews and has many users through reviews. And finally the reviews model, which is the join table, belongs to a user and belongs to a food truck. I also added validations for content and title. I didn’t want users leaving blank reviews after all!
Omniauth Strategy: Google
The first thing I wanted to do was create my log in feature. I used Omniauth to allow a user to sign in with Google. I followed the instructions and documentation here. This piece was fairly straightforward.
The first thing you have to do is sign into to Google and get your API key. Add gem ‘omniauth-google-oauth2 ‘to your gem file and then follow the instructions for the API setup. 'Though do be forewarned, when you first get it set up and go to test it out, you will get a bunch of crazy looking errors because it can apparently take up to an hour for the functionality to work. So don’t do what I did- which was to panic for a full hour scouring the internet trying to figure out why your sign in with Google isn’t working. Do yoga. Go for a walk. Maybe eat a snack.
Set up Those Controllers
To finish the Omniauth functionality, you will need to create a Sessions controller and add a method that lets other developers know what it is you're doing. My sessions controller looks like this:
This creates a new session and also clears an existing session. After this was taken care of, I got my Users, Food Trucks, Reviews controllers set up. For this step, I really had to think about what views I ultimately wanted. The food trucks controller was the logical place to start. I wanted my home page to just be the index of all food trucks. So I built out an index method as well as a show method. For me, the tricky thing about rails is that there is a LOT of abstraction going under the hood. The “magic” as it’s called. This is great because Rails takes care of a lot of things for you, but it also makes debugging difficult at times because it’s not always clear where the issue with your code lies.
Views, Forms, and Scopes
The views was where things got tricky. I had to do a lot of debugging and byebug-ing on this project to figure out why certain forms weren’t working or why I kept getting errors. Especially when you’ve got various associations, nested resources and routes, things get complicated quick. So I started with some basic views. I need a Profile Page, aka a show page for the user, a My Reviews page, which was a show page for the reviews, and an All Food Trucks page, which was an index page of food trucks. The search feature on the index page is for querying the database and returning only food trucks that match certain params, in this case cuisine and name. I used a scope method, which is just syntactic sugar for a class method, to build out this functionality.
This app was a lot of fun and also really challenging to build out. In the future I’ll add some java script, integrate the Google Maps API, and add more CSS and styling. The best part of this app for me is having all the schedules for my favorite food trucks all in one place. You can check out the git repo here.