Interested in trying it out?

Nutritionix, i.e. the backbone of the project, allows free use of its API only up to 200 calls of an endpoint critical to the project each day. The count will have reset by the time judging is meant to begin. In the meantime, I'll have a few major features disabled to make sure my API calls don't get rejected at inopportune times.


Have you ever used a mobile app that keeps track of your eating habits for dieting purposes?

If not, here's the gist: when you have anything to eat or drink, you're meant to open the app, type in the name of what it was you consumed, and the precise amount you consumed. The app then tabulates the nutritional information associated with the particular entry you selected, and helps you to keep track of your nutritional intake throughout the day.

It's a fine approach, but not without its annoyances. These apps must, by design, build as large a database of foodstuffs as possible to minimize the possibility of a user eating something that the app can't account for. Even if the developers can accomplish that more or less successfully, the end user will almost invariably find themselves having to manually input individual ingredients anyway after some meals. For example, say you get a quick-service burrito at a popular chain restaurant. Say you can get many different combinations of fillings. Since it's infeasible for the app developers to write up nutrition facts for tens or hundreds of thousands of combinations, the best that the user can do is to manually add each individual quantity of each individual ingredient... hardly any more feasible.

I've tried to find a happy medium between the two extremes.

What it does

The collector implements the Nutritionix API, which allows it to search through Nutritionix's database of nearly a million retail foods, restaurant menu offerings, and generic items. The user is meant to enter the name of any food, beverage, brand, or combination thereof. Once they hit the "Search" button, the program sends a GET request to an endpoint associated with the Nutritionix API's search function, returning the results as a list of closest matches.

For any item in this resulting list, the user can click one of two buttons:

  1. The "Display Nutritional Information" button, which sends a GET request to an endpoint associated with the Nutritionix API's item detail function. This is a JSON object containing a substantial amount of data; of interest are entries for everything one would find on a Nutrition Facts panel. After the API's response is received successfully, the program displays it all to the user in an easily recognizable format.

  2. The "Add to Recipe Builder" button, which adds all the nutritional information from the item in question to a running total. The "Show Recipe Builder" button then displays the items that were selected and the combined total of their nutritional data. Now, after the quick-service burrito, the user can simply enter the name of that restaurant, and all of the items that they would've been offered will show up right away. The user simply presses the "Add to Recipe Builder" button on each item they selected when they ordered, and then one more button press will reveal the total nutrition consumed _ dramatically _ faster than creating individual entries for each in a diet-tracking app. This project could easily serve as a framework for developing a competitive alternative to existing apps like those, but even now, it could be used as a helpful companion to them, since even manually entering the totals obtained from the project into another app would be faster than manually entering everything individually.

How I built it

The Collector is written almost entirely in HTML, CSS, and JavaScript. It also implements the jQuery library to simplify the process of calling the Nutritionex API, which is the foundation of the entire project. The result is a responsive and scalable application that's ripe for expanding upon.

Challenges I ran into

I've wanted to figure out how to implement RESTful APIs for a considerable amount of time. This weekend, I finally decided to buckle down and do it, which ended up being the most challenging part. Aside from that, I'm no web designer, and making a user-friendly interface for the project required me to expand my knowledge of HTML and CSS quite a bit.

Accomplishments that I'm proud of

Writing a functional application centered around the use of a RESTful API, and building a robust interface to support it.

What I learned

A whole lot of HTML, a whole lot of CSS, and a whole lot about the interaction between my own machine and a far-away API

What's next for Nutritionix-tend

The Collector as is remains short on some of the polish and modularity that most investors would expect. However, it represents an excellent framework for building a marketable and competitive product in a field that continues to suffer from avoidable bottlenecks in usability and user experience in general.

Share this project: