Restraunt App(WIP)

On-going

This is my current project, it’s an application for practice, fun and practical use. In Hong Kong, I have difficulty finding restraunts that I like or my friends like, and when I do find those spots, I have difficulty remembering them, and so do my friends. I wanted to come up with a solution to remember where these restraunts are, how far away from me they are and what kind of restraunt.

The main considerations to solve this -

• Make adding restraunts painless - easy and quick for users
• Nearest restraunts should be shown quickly
• Location calculation should be somewhat accurate without being too expensive in terms of processing power, time and money.

The really interesting part was how to solve the location issue. If I am walking around the street, and I check the app, I want to see the closest restraunts to me. There’s many ways to calculate distance available, using something like google maps api would be expensive and long depending on scale, be a bottleneck. Something like Euclidean distance would be too inaccurate, however, there’s a formula called Haversine formula which for smaller areas, i.e Hong Kong is suitable. It’s an inexpensive formula to calculate distances with cordinates that doesn’t need more than even single core cpu on a cloud VM.

If I was to navively get the cloest restraunts near my user, I would compare the user’s location to all restraunts in the database, which is impractical and inefficent. With a single user and 50 restraunts, that’s 50 calculations. With 100 users and 50 restraunts that’s a max 5000 calculations. To solve this I came up with a tree style optimization method.

MTR is the most common way to get around in Hong Kong and seperate districts which led to the idea of creating ‘district points’ as a way to seperate restraunts and reduce the calculation cost.

Each restraunt can be tagged with a district and each user will have a closest district when they check for closet restraunts. The cordinates of these districts can be stored in the DB beforehand. When adding any restraunts to the app, the user can enter a google maps link, this will get the cordinates from google maps and this can be cross checked against the district cordinates to find the closet one.

When the user then checks to find the closest restraunts in 1km for example, it’s easy to find the closet district to them, and just query the relevant restraunts, reducing the scope from every restraunt in the country to ones in thier area.

However this has another issue - what if a user is near the edge of a district? There’s another layer of complexity that needs missing. When adding districts to the DB, there needs to be another calculation to find districts within a certain distance, i.e 5km and mark them as neighbouring districts. Then when quering, the nearest district and the nearest neighbouring district’s restraunts can be taken into account to get an accurate view of closest restraunts to the user without using too many resources and doing it efficently and correctly. Of course the distance measurement isn’t optimal but when walking, 50-100m inaccuracy is a acceptable comprimise between user satisfaction, cost and time

For the technologies, the app needed to be something easy to use, so phone app was a clear target and I chose flutter because I wanted to learn it in more indepth and it’s perfect for a cross-platform light-weight application. I mocked the front-end using figma and have currently setup the login and adding restraunt flow, and am currently developing the showing restraunts in your area widget.

For the backend, I’ve developed the find restraunts system including all the optimization, as well as adding restraunts and building my authentication and security with Oauth2 format using JWT tokens in a REST style api with Spring.