What made you want to build this hack?
No matter who you are or where you are, the question “What should we eat?” can be a frustrating one for couples, families, individuals, and groups of friends looking to satisfy their appetite. The question is asked almost every day, and according to a 2017 New York Post survey, respondents on average spend 2 hours and 32 minutes a week negotiating on what type of meal to eat. In fact 87% of couples surveyed said it was a problem. Furthermore, great new discoveries are not always easy to come by, as 61% find it difficult to discover new restaurants. As the economy across Canada reopens following the lockdown measures, more than ever consumers will be looking to rediscover their own backyards.
How it works (high level)
Enter WhatEat. Based on your eating occasion and preference of cuisine, price, distance, WhatEat randomly generates a restaurant for you to go to, eliminating the ‘choice overload’ associated with selecting a restaurant. How it works from a technical perspective: After only 4 clicks, WhatEat will query search results and filter for preferences such as cuisine type, rating, and price through a Yelp API integration. WhatEat will also identify the location of the user to help find a restaurant within the preferred radius, and will provide the address link through Google Maps.
What is your tech stack?
The front-end was built using Vue.js with custom styling to represent our brand image. For the backend, the initial plan was to use a Node.js service deployed to an Amazon EC2 instance. However, we decided to simplify the app to the point where a database would not be required. “Serverless” options such as Amazon Lambda were considered. In the end, Autocode seemed to fit our use case well because it was easy to learn, stored our secrets securely, and was overall an incredibly fast way to make application logic available wherever we wanted.
What was the most challenging part of the hack?
No one likes a project that only works in your local environment. We wanted to build something that we could share with friends and come back to, while always being available for use. Therefore, the main challenge was to have production ready versions of part of our software stack, while fully leveraging the resources provided to us in the Hackathon. There is also the obvious time constraint and multiple points of failure between a user coming to our website and finally getting a recommendation Most importantly, we needed a user interface we would be willing to use ourselves, so a large amount of time was invested on testing the full flow of the application and being nitpicky about the smallest things. By doing this, we were able to build a quick, convenient tool that we can share with everyone.