We wanted to create a program that would help us navigate interacting with an interesting API, with all the challenges involved with that to help us learn! It meant making sure we collected and delivered data as required by the API, processed the response appropriately, and otherwise worked within the constraints of a third-party resource. From there, we looked through lists of APIs online for inspiration, and happened upon a few APIs that deliver recipes based on a series of parameters. We decided to make a meal planning app that can help you decide on dinner for the day or for the week!
What it does
The user can choose one of two modes: Daily or Weekly. In Daily Mode, the user provides their minimum and maximum # of calories and the diet and health needs they'd like to adhere to. This initiates a call to the API to find a recipe that fits the user's needs. The web app then displays the details about the recipe, including ingredients, nutrition facts, a picture, and a link to the recipe itself. The user can also go back and edit their parameters from this page via the Edit link.
The Weekly Mode is similar, but plans out an entire week, finding meals that all fit the appropriate parameters. It determines how many days of leftovers a recipe will produce based on the number of servings the user provides and distributes meals accordingly. From the weekly result page, the user can click through to each recipe.
How we built it
We build our web app using Node and Handlebars primarily. The Node side handles calls to the API, and populates the context for the handlebars pages.
Challenges we ran into
Many of the challenges had to do with the API itself. We had a preferred API, spoonacular, that turned out to have a too-low request limit for the free version to suite our needs (especially for testing), so we had to switch to the Edamam API, which was also useful but had much more limited query options (cannot define the type of a meal, cannot query based on the number of servings in a meal, etc). Therefore, we had to include functionality to check that a returned recipe had enough servings, and for the weekly version, to calculate the number of servings used up each day to distribute the recipes appropriately throughout the week. We also had problems in testing with restrictions on our API access that we hadn't realized previously, and so had to diagnose our authorization problems.
The API also presented challenges for the front end because the strings it returns can be unpredictable. We dealt with overflow of titles and list items, which we were able to solve in places with scrollbars but which still present some aesthetic issues in places. Given more time we'd love to work on a fix for things like this!
Accomplishments that we're proud of
The app is finished and functions, which we're definitely proud of! We're also glad that we were able to achieve some of our stretch goals, like having a weekly option as well as a daily option and accounting for servings instead of assuming the user was eating alone.
What we learned
We used some technologies we all familiar with so we could work quickly together as a team, but we reinforced how to construct the folder structure for a node project using handlebars, how to diagnose and solve HTTP request issues, how to use Axios (a promise-based HTTP client for Node), and how to navigate and troubleshoot a third-party API with limited and sometimes unclear documentation.
What's next for Team Delicious: Meal Planner
Some things we could work on given more time: -Ensuring all meals returned are appropriate for dinners (potentially inplausible with this API, but we could switch to another) -Building a dynamic front end to deal with variable returned string lengths -Allowing the user to preview the recipe information in weekly view before navigating to the recipe page -Opening the recipe information in a new window or tab -Randomizing the recipe selected from the return array so that queries with the same parameters would be more likely to return different results