alexander0042

The the end of the day, the real reason I went with Lambda to build this is that when I started, I didn't know anything about spinning up a server, building a storage array, or serving an web request. But what I did know was how to write a Python script to extract weather data from a file. The really cool thing about some of these cloud tools is that they let me ignore all of those (very difficult) problems and just focus on the data

You clearly know way more about cloud implementations than I do, so I really appreciate the time you took to explain that out! Since I am the dev here though, the one things I can confirm is that you're 100% correct about the setup methodology- almost every decision was based on "how can I do this in a way that's cost effective". In particular, the underlying data was already on AWS, so it just made sense to build it there.

I think one thing that gets lost in discussion is the advantages of serverless approaches for people without a ton of technical background. I built 90% of this without knowing anything about servers or APIs, but the cloud tools (from whoever) let me ignore all of that and just write a bunch of Python scripts that do cool things. I know it ends up sounding a bit like an AWS ad (I wish I was sponsored by them, but am not), but there really are perks to the approach

It's a real issue, that's why I made my own! The beauty of an open source one is that if things start to go off the rails, someone else could also pick up and recreate the data source

This is a limitation of how the Developer Portal is set up, you have to be registered to view the APIs. Like the other poster said, if you're looking for general info, go to the docs section, since all the information is there

They (sort of) are! It gets into the nuance of the weather model side of things, which I don't know as much about, but the HRRR/ GFS models ingest data from APRS and incorporate that into their forecasts. This means that these observations are included (especially in the US), but are at about a 2 hour lag compared to direct readings

Thank you so much! I really want there to be a free level available, and it's donations like this that make it possible

This is fascinating, thank you for sharing! What is even more amazing about Dark Sky is that they did this in 2011, when a lot of the tools I have access to now didn't exist. For Pirate Weather, I avoid working with radar data at all, instead using the 15-minute forecast that the HRRR model provides

As the dev who set up the Pirate Weather source, I couldn't agree more. 90% of the challenge here was getting the grib files into a format I could quickly and easily access, since the provided format is about as difficult as it gets. I don't pretend to know more about the actual art of forecasting than NOAA, but wanted a better way to get the data they produce out there

I'm the dev behind this, and really appreciate all the insight from actual cloud professionals! Your guess here is spot on, I designed it so that I could more or less fit in the free tier with exactly one user, with costs scaling pretty linearly afterwards. There are a few more optimizations I could do, but it's honestly pretty impressive how much traffic (I'm at about 10 million calls/ month) can be (somewhat) cheaply handled using AWS

This is like the 5th iteration of that darn diagram, and I still can't quite get it right. The other comments are correct, the underlying setup isn't that complicated, and it wouldn't be too tricky to build it for another cloud, since all that's really happening is a Python script reading a NetCDF file. The real perk to building everything using a server-less approach was that everything scaled down to 1 user (me), and then has scaled up beautifully as more people have signed up.

The monthly bill isn't great, but has been manageable through donations so far. I'm handling about 10 million API calls/ month, so lots of Lambda invocations, but they're all thankfully very short with tiny outbound data transfer totals, and luckily inbound is free. If the costs ever get out of hand is to throttle the request rate down, but there's still a few optimizations I can do on the AWS side that should help (ARM here I come!).

I'm the dev for this, so can shed some light on this! Weather Underground was a pretty out there choice- I guess the kind of people who like putting together weather APIs aren't great at naming things. I considered "Bright Ground", and still have the domain name for it, so maybe it'd be worth spinning up another API endpoint/ branding that uses that and has a more commercial focus, keeping Pirate Weather as the free and open source branding.

Good question! It's the same underlying models, but three key differences: 1. Pirate Weather returns data following the Dark Sky syntax, as opposed to the custom NWS format. 2. Pirate Weather has global coverage, the NWS API is only for the US. 3. The NWS one uses human forecasters to come up with their forecasts, compared to Pirate Weather's use of raw model results.

I'm the dev behind this, so always great to hear things like this! I really struggled to try to come up with a name. My first thought was "Bright Ground" (opposite of Dark Sky), but that seemed a little too on the nose. Luckily, the legal aspect of this (I'm in the clear!) was pretty well settled after the final Oracle v. Google case, but at the time was a big enough deal that it seemed relevant, and the HRRR model was another plus. I should update that README though, since it's now very definitely legal!

Hi,

I'm the dev behind the Pirate Weather API. I really appreciate your feedback here, since I missed that typo, but it's fixed now.

I went through a ton of iterations of the subtitle, since it's a tricky thing to get right. I think the "Open" part is important, but agree that I don't want it to be confused with "Open Weather Map". I've retitled it to "A Free, Open, and Documented Forecast API", which is a little wordy, but might be better