The Final Design of Our Website
Our brainstorm board, where we discussed what our project should and should not include
Our Mock-up of the user interface, including a filtering menu to the left and data on the rest of the page
The architectural design of the application
Our design for database tables. Having it on a board helped us to keep a consistent model across SQL, Groovy, and React
One of our potential designs for how the website would specify a filter when making a request. This one was scrapped later
Our example postman request detailing our final design for filtering from the perspective of the front-end
While we were brainstorming ideas for the hackathon, the gang all got pretty hungry and decided to grab a bite to eat and refuel ourselves. Since Ryan is vegetarian, it limited the number of places we could order food at. Even if there were plenty of restaurants nearby that offered vegetarian options, it's time-consuming to visit the websites of each establishment and read through the menus to look for any available options.
We then had an idea. What if you could easily view all nearby restaurants on one site and filter them by dietary needs? What restaurants have vegetarian options? Which restaurants have affordable meals? Which restaurants have gluten-free options?
What it does
MenuMe acts as a standardized platform for restaurants in the Lincoln area to upload their menus. It also helps individuals with specific dietary needs to easily find potential meals, even if they're visiting a city they've never been to before.
How we built it
It took us a couple of hours to collect all of our ideas and get a clear picture of what we wanted in our application. We drew out a rough user interface and brainstormed what things we thought would be good to be able to search by.
After this, we worked on the application’s rough architectural diagram for about an hour:
The database model took about an hour to finalize. Most time was just spent deciding if moving some enums to separate tables was necessary or not.
The Groovy application underwent a few redesigns for its filtering algorithm but was eventually finished around 7 PM on Saturday. We used Spring data and Spring web to simplify API design and database-API interactions. Below is one of our original ideas for how we would model filtering in JSON
Challenges we ran into
It’s the first hackathon for most of us, so we weren’t used to having to plan out and launch an application in such a short amount of time. It required a lot of communication and trust between each other that each person could do what they’re assigned. We had to prioritize work so that the tail-end of the competition was just spent making sure the back end could connect to the front-end correctly.
None of us have ever really done anything in React, and we all have little front-end experience, so it was super difficult for us to build out the front end. It felt like half of the time we fixed something, we weren’t even sure what we did.
While one of us has worked on Spring applications before, none of us have ever made one from the ground up. A decent amount of time was spent just getting the database connection configured correctly. It was also the first time that any of us had implemented a dynamic filtering algorithm, where you can filter by as many or as few fields as you want. Some issues were run into with Groovy lacking a parrot parser function below version 3, and the alternative to it not working as we need for getting constructor Functions. That, among some other issues, caused us to need to redo our filtering architecture three or four times.
Additionally, while individually each of us individually had used GitHub for pushing and pulling code for coursework, none of us had ever used it to collaborate with other students in a project of this magnitude. Because of this, with pushing and pulling to multiple branches as well as simply being able to adequately manage these branches all at the same time, we ran into many problems. One such example required deleting the entire repository on your laptop, creating a new react app folder, and completely reinstalling all of the necessary react related components on your computer, a process that originally took hours to figure out and put into action to be able to get back working together as a team on the project itself.
Overall, while we faced many challenges throughout this project, the learning we were able to achieve from pushing ourselves to create this massive endeavor was entirely worth it and I’m excited to see where the application of these newfound skills takes us in the future.
Accomplishments that we're proud of
About eight hours were spent by one of us just getting the dynamic filtering algorithm working. We went through a few different redesigns, first generating and combining Predicates, then by combining Specifications in a type-generic filter object. We eventually scrapped the type-generic filtering because there were some issues with attempting to filter when you can’t even be sure what the object is and because we only needed to filter restaurants. Even then, the Baeldung documentation we were following was written for java so their Function reference to the constructor using a parrot parser would not work in the officially supported groovy version in Gradle. Eventually, we just had to make a filter function that just checks if a bunch of fields is null in a request and filters by non-null ones using some SQL queries.
We also came into this with next to zero knowledge in React and still managed to build out a functional website. While it may not look the prettiest, we are still proud that we were able to learn enough React in 24 hours to get something running.
What we learned
We all learned a lot about development. While we aren’t necessarily comfortable in React yet, we definitely have a bit more confidence in what we’re doing. We’re all freshmen, so it was the first time any of us had to create both a front-end and a back-end for a project. We weren’t sure that we’d be able to even get the two to connect together until the very end when we were able to successfully retrieve results from the database using our website at 3 am on Sunday.
While we didn’t end up sticking with our original designs for filtering objects, we did learn a lot about the quirks of Groovy and where it starts to have some downsides in comparison to Java. One of us has had experience in Spring, but he still even learned new concepts as well as applications of things he already used before.
What's next for MenuMe
Once we’ve learned a bit more about creating user interfaces, we plan to redesign the UI to improve readability. From there, we’d probably make a few more quality-of-life changes before an initial rollout to our college campus, gaining critical feedback on features both from the restaurants and from the customers. While we don’t think our application is by any means revolutionary, it does address some degree of need.
We also plan to research Google Maps’ API and utilize it for more information regarding restaurants, such as wait time, distance, directions to the restaurant, etc. This would allow for a lot more data, and likely more accurate information regarding how to contact the restaurant. A discussion would need to be had on if we would continue to have restaurants voluntarily join the service long-term, or if we would start relying on something such as Google Maps and some scripts to automatically try and pull-down menus from restaurants.
With the way our REST API was designed, it would also be easy to allow third parties to incorporate our product into theirs. For example, DoorDash would be able to pull our data into their application, and users could set allergies and have the app automatically hide any results which they would not be able to eat at. It’s likely that the product we are designing is better suited for integration into pre-existing services. However, what has been built out serves as a great proof-of-concept for addressing the need that we’ve identified.