Fivily: Database Structures & API Consumption

February 23rd, 2015 - Ubud, Bali

With just a few weeks remaining in the bootcamp, our projects are growing more difficult, bringing added layers of complexity and progressively more vexing challenges. We spent the entirety of last week split into three groups: two built food ordering web applications and the third built an API named "Expenserizer" that would handle the financial data from the other two teams. By the end of the week, we were able to get all of the apps to send and receive requests to each other, which was a huge feeling of accomplishment. Here's a breakdown of how my team decided to approach the task at hand:

Problem Statement: Build a banquet planner application that enables users to create orders of catered foods, including Soups, Salads, Sandwiches, and Desserts.

After being provided with some example user stories, we began by breaking the potentially complex into bite-sized chunks and focused on the core functionality that would make the app work. We studied interfaces on Eat24 and IndoPanda (food delivery sites), paying close attention to how they structured their data and how users progressed through the ordering process.

Recently, everyone in the bootcamp has been saving time during our lunch hour by ordering ridiculously delicious Indonesian food from a delightful woman named Fivi who is in the opening stages of starting a restaurant and catering company, Pisang Manis.  Seeing as Fivi has to send us Facebook messages or drop by the villa each morning to collect our orders for lunch, we thought it would be helpful to build an app that enables Fivi's customers to submit orders.

We starting by analyzing the menu, and began sketching out how to structure the data models. After much deliberation, we settled on our initial schema:

The most important aspect of our concept turned out to be the Order_items table, which acts as a join table. It connects Items and Orders so that specific items from the menu can be added to a users order. Here's what the code looks like behind Orders. Notice how it belongs to items through order_items. 

After a few days, we were able to piece together a coherent user flow that enabled users to sign up, add items to an order, and checkout. Here's the landing page with an order ready for checkout:

While we were building out Fivily, four of our peers were working on Expenserizer, an API that would focus on handling expenses from the two other teams. You'll notice at the bottom of the order, we added up the subtotal. Let's explain how we could send that to Expenserizer.

API Integration

If you've never heard of it before, just think of an API (Application Programming Interface) as a way for apps to talk to each other. They are an amazing type of software that most people use everyday.  Remember the last time you entered your credit card information on a payments form? That was using an API. Maybe you signed up for something recently and clicked on "Sign up with Facebook?" You used an API. Or how about a Google Maps view built into another website? Yup, that's an API.

After a few days making progress along separate paths, we began to collaborate with the other teams and submit requests for what features we wanted the API to exhibit. Below are two of the most fundamental: Fivily should be able to send Expenserizer data (through the cloud) using the create_expense method, then receive data sorted into specific date ranges using the get_expenses_date_range method.

It's a huge help to make mental models of how complicated features work, but talk is cheap...show me the code:

Notice how we're first authenticating the user with their name and unique token, then passing through the data: parameters for date and amount. In the future, Expenserizer could build out additional methods for determining profitability or create views visualizing the data's trends and insights.

It was a great feeling to finally successfully submit orders on our computers and watch them show up in the log file on the API. We've got a few more changes to make before deploying the final version, but we've published the code on Github. Here's to taking on even bigger challenges in the week ahead!