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.

5 comments

Contortion

Reply
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!

  • Svip  2 days ago

    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.

  • echoangle  2 days ago

    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?