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!

OOI, would you expect the output to include a single days weather (like the site does now), multiple, or options for both?

I’m starting to think about dedicated sub pages that cover these use cases, with a single section on the main page that links into it. A sailing based page could definitely work here!

Open-meteo has a very generous free tier, and reasonable pricing. It also lets you fetch weather from previous days, which I’ve included so you can see if it’s relatively hotter/colder etc. than yesterday.

I’ll take a look though at whether there’s anything causing fundamental slowness in the cache read / page rendering pipeline.

I agree, it’s definitely something to work on as it takes up a considerable amount of vertical space.

I found the precipitation chart challenging as you need to present both the forecasted precipitation, and the potential likelihood of the precipitation occurring. Something I’ve considered is using a horizontal graph with different shades of grey through black in each bar to represent the probability, but it would somewhat reduce accessibility.

I made https://brolly.sh, a minimalist, plain text weather forecasting site. You can use it to view weather from around the world, with: 7 day forecast; Previous day log (so you can confirm it definitely was cooler / hotter / wetter / drier yesterday!); Hourly rain, wind, temperature, conditions; Hourly UV, air quality and pollen, including pollen type specific forecasts within the EU / UK; Location search and last 5 locations; Location specific units.

I mostly made the site for myself, if anyone else also benefits from it that’s an added advantage.

You can check out the weather in York, UK at https://brolly.sh/forecast/RWFP2qW8, or search for a location at https://brolly.sh

The site is deliberately styled as a single long scrollable column, to work on mobile phones. You can view it on desktop too, there's just a lot of horizontal padding. I naturally took a lot of inspiration from plaintextsports.com. Despite not being a sports fan, I love its aesthetic. But, you'll hopefully see that this site isn't a rip off, and has its own deliberate look and feel.

Visualisations are really important to showing information at a glance. I spent a lot of time designing the different visualisations and making them work with only characters. My favourite is the hourly heat map used for pollen count.

It's also frustrating to have an interactive site, where you can't share a page with a friend and have them see what you're seeing. To solve this, all page state (i.e. location, selected day, expanded / collapsed sections), is stored in the URL. You can share or bookmark the specific view, and know that you'll always be able to come back to it.

The site uses PocketBase. It’s written in Go and plain HTML/JavaScript/CSS. All pages are backend rendered, with light JavaScript to handle re-loading content without page jumps when using interactive features like next / previous day navigation. Weather forecasts are fetched from open-meteo.com, which has a very generous free tier. However, I also built a custom LRU cache on top of PocketBase’s SQLite DB to cache forecasts for 5 minutes, and avoid putting unnecessary pressure on the open-meteo API.

Comments URL: https://news.ycombinator.com/item?id=49049693

Points: 227

# Comments: 84

This functionality is called ‘break back’ in a lot of enterprise modelling software. See [IBM TM1](https://www.ibm.com/docs/en/cognos-planning/10.2.1?topic=bre...) and [Anaplan](https://help.anaplan.com/breakback-1b7aa87d-aa13-49f6-8f7d-d...). They generally work in terms of scaling the inputs to match the new output though, which is a bit more basic than this approach.

Comments URL: https://news.ycombinator.com/item?id=19984958

Points: 4

# Comments: 0