Comment by jsax
2 days ago
It’s a good question. Initially, the URL was lat/long values, and then I did try place names. I ended up with the short code approach to minimise API calls to downstream services.
The short code in the URL is generated at search time, and maps to a location name, lat/long, altitude etc. within a table. It’s generated off of the location name, so two people searching for the same place get the same short code.
The short code enables a forecast lookup to be a SQLite DB read, followed by a single API call for the forecast.
A more descriptive URL would have required two sequential calls - one to figure out the lat/long and/or place name, and another for the forecast. This wasn’t a huge speed problem, but I struggled to find geocoding APIs with generous free tiers or reasonable low volume pricing. It would have also made the forecast at a given URL somewhat non-deterministic, as the geocoding API could change its output or preferred result over time.
Short codes quite possibly wasn’t the right solution. It’s definitely something I’ll think more about. Thank you!
How about adding the location information as a suffix to the short code, e.g. `/forecast/<shortcode>/united-kingdom/yorkshire/york`? The latter part of the URL is of not use to the site, but is useful for the user.
I don’t get that reason, couldn’t you just use the location name as a field in the database just like you use the short code right now? Where’s the additional API call on lookup coming from?
Re-read their response. They answered both these questions.
I still don’t get it.
Situation a: Someone searches for location XYZ. The geocoding API returns lat and Lon and canonical name ABC. You save that and the slugified name abc in your DB. (If the API doesn’t return a name, you can use XYZ instead of ABC). You return slug abc to the user.
Situation b: Someone requests weather for location at slug abc. You look in your DB, ask the weather API for the weather at lat/lon and return that to the user.
Situation c: Someone searches for a place that happens to already exist in the DB. You geocode the search term and get a lat/lon pair that’s already in the DB so you return the saved slug.
How is that different than using a shortcode? In which situation are you doing a geocoding API request you don’t need to do with the current system?