xxlovy / ibslover Goto Github PK

In most cases, the bathroom information for a specific area won't drastically change within a single day. Under this premise, if a user conducts a search and the result is within the vicinity, say about 100 meters, we can save this result into the database. If another query is made by any user within this proximity shortly afterward, we can swiftly provide the results from the recent search instead of querying again.

This strategy will serve to boost search speed and reduce the frequency of Google Maps API calls. Considering that this app has a core user base—likely individuals with IBS, who are the main users—it's highly probable that these frequent users will perform queries within specific areas. Thus, relying on our database for rapid searches can alleviate the need for constant Google Maps API calls. I'm even contemplating whether we could leverage a fast-caching system like Redis instead of traditional databases such as MongoDB for speedier retrieval.
For the sake of data accuracy, the stored queries would be refreshed daily.

Currently rate limit is done using redis server as a counter and count requests from every IP, there are better ways to do this, for example:

Cloudflare solutions: https://www.cloudflare.com/application-services/solutions/#protect-websites-applications-solutions
and/or
express rate limit middle ware: https://www.npmjs.com/package/express-rate-limit

The backend service lacks measures to prevent flood attacks. If the backend service API is reverse-engineered, it can be flooded with a large number of requests in a short period of time, leading to economic losses due to excessive calls to the Google Maps API.

Currently considered mitigation strategies:

1. Google Maps API Key Usage Limitation: Apply a usage limit to the Google Maps API key. Each call increases the usage count, and when the usage reaches the daily limit, no further access is allowed.
2. IP Usage Limitation: Restrict the number of requests from the same IP address within a short period of time.

Limitations

• Theoretically, attackers can still conduct flood attacks by changing IP addresses. However, due to the usage limit imposed on the Google Maps API key, economic losses can be mitigated. Nevertheless, subsequent users may be unable to access our service.

Description

Current Implementation: As it stands, when a user submits a new toilet location, the system checks the database for any existing toilets within a defined range, (let's say 20 meters). If a toilet is present within this proximity, it's assumed to be the same one, and the existing entry's vote count is incremented by one. If there is no matching entry, a new toilet with a vote count of one is added to the database.

Issue: This method presents a challenge when the user's GPS location isn't precise within 20 meters, leading to potential errors. One idea I'm considering is to insert the user's data into the toilet entry when a toilet is detected within the 20-meter range in the database. Subsequently, when displaying this data, the system would calculate the average of all the coordinates for that specific entry, resulting in a more accurate toilet location.

Seeking Better Solutions: I am exploring if there are any better methods to enhance the accuracy of this feature.