Comment by Contortion
2 days ago
Is there a reason why the URL parameters are obfuscated? I think it would more user (and SEO) friendly to have at least the place names in the URL, e.g. brolly.sh/forecast/united-kingdom/yorkshire/york.
Still, great project! Definitely fulfils my desire for minimalism in all things.
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.
1 reply →