RecipeReady

Inspiration

Imagine you're coming home after a busy school/work Friday, and you open your fridge only to find a sad box of leftovers from the previous night. Not only do you simply not want to do or decide anything, you don't want to do anything tomorrow either — tomorrow's the weekend! — but you can't just go a week without food. So, you grumble and pick up whatever groceries at the last minute, and then you're miserable for the next week as you eat nothing but spaghetti with canned tomato sauce.

RecipeReady solves all of these issues by taking it on itself to do them for you! No longer will you need to exercise precious brainpower, which could otherwise be used to solve the world's problems, on deciding what to eat — one click of a button, and the app will give you a recipe plan and a grocery list for however many people for however many days you choose until your next grocery trip.

What it does

RecipeReady is an mobile application designed to do exactly what we hated to do manually: making decisions about what to eat. It chooses the best recipes taken from all over the internet and randomly suggests them to you at the click of a button, along with an automatically generated grocery list that takes all of the ingredients you'll need for the week and sums them all up for you.

If you don't like a particular meal RecipeReady suggests for you, just swipe left and RecipeReady will rush to replace it with something of your liking. Among everything else people have to plan in their lives these days, it makes sense that food would be the first to go.

How we built it

RecipeReady is a modular collection of tools that work together to provide a cohesive experience.

Beginning with the massive amount of data RecipeReady needed, we had to find somewhere to put it that we could access easily and quickly.

So naturally we chose on-disk JSON!

Of course not — we actually worked with a database: CockroachDB via CockroachCloud, to be precise, because of its flexibility and scalability no matter how small our data set we threw at it. It handled our tags and our requests easily to the point that the API we developed was the larger bottleneck. :P

A powerful storage database is nothing without data to actually store in it. In order to feed the hungry machine, we developed a scraper with the help of some libraries (selenium, recipe-scraper) to gather raw recipe data from potentially dozens of sites and parse them via several APIs (Edamam, Walmart) to make it easier for our software to read and transfer around as well as glean more information, such as nutritional data, pricing, and dietary restrictions. This tool at peak efficiency managed to scan through an astounding 60 recipes per hour, truly unparalleled and optimised at its best.

At this point we had our data — but then we realised that it would not be entirely a good idea to allow the client to make SQL requests as they liked, and just in case for the future it would be way nicer if there was a standard API for us to interface with our database, so we built one using FastAPI, an efficient Python framework that let us finish the backend much earlier than originally anticipated.

Now that we had all this data and infrastructure (scraper > database > API), it was going to be a real shame if there was no frontend to see it.

And that's where the Flutter app was created! Regardless of our graphic design skills, we built a clean, performant, and dare we say simple application that happily consumed our API.

Challenges we ran into

As relatively inexperienced programmers, we faced challenges with pushing out of our comfort zone and exploring new technologies and new ways of using those technologies.

We relative newcomers to frontend development (only one person had ever developed a mobile UI!) found it to be very different from the other types of programming we understood more, and most of our time during the hackathon was spent on patching up the frontend and working against the framework to do something there was a much easier way around.

However, feature/scope creep was another issue we were aware about: our scraper obtained much more data and our API gained many more functions than originally intended to the point that we couldn't implement them all in our frontend. Not only was much of this unused, it also wasted valuable time and effort that could have been spent polishing our core ideas.

Accomplishments that we're proud of

We're extremely proud of our final product, which we think is a capable and useful program that addresses a need not commonly observed. We're also proud of the steps we took to reach this point, including:

• building different programs that do completely different things
• making those different programs work together to do the same thing really well

What we learned

Throughout our 36 hours at Hack the North, we appreciated the time management and planning we put into this project beforehand to make it run much more smoothly than it otherwise would have. Of course, we've also learned new technologies, as tagged below, and we now know that throwing more features at a program isn't a great idea, particularly as a deadline looms closer and closer.

What's next for RecipeReady

RecipeReady still has a long way to go. The features we developed on the backend but never had the chance to implement in the frontend could be included, including extremely detailed nutrition information and filters, a "like/dislike" system that would be used to recommend similar recipes or never see certain ones again, and smarter natural language processing that would be used to augment our existing ingredient detection and collation.

Built With

• api
• cockroachdb
• dart
• database
• db
• edamam-nutrition
• flutter
• json
• python
• selenium