Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
To me it's a bit worrying that someone who is still is a student, builds such a complicated and hard to maintain architecture (https://github.com/alexander0042/pirateweather/raw/main/docs...). Maybe it's complicated on purpose, to educate themselves on how to create infrastructure like that, but for a production environment, you want to keep things as simple as possible.
I'd have opted for a setup where basically every single "service" in that architecture diagram is one function in a monolith program. Easier to maintain, more performant, easier to deploy and basically better in every single way except you can't individually scale components. But at the scale that the project currently is, I don't think that's needed for a long time, nor is it hard to scale one machine if needed.
But again, if it's just a educational exercise in "web scale architecture", then it of course is OK. But I wouldn't want other students to see something like that and think that it's necessarily to create such a monster for a relatively simple "moving data around and wrangle it a bit" program.
On android I use NativeAlpha for setting up Briefsky as app that opens in its own Android Webview app rather than a browser. It's almost like DarkSky minus the notifications.
https://github.com/cylonid/NativeAlphaForAndroid
I am building another open source weather API: https://open-meteo.com. The architecture is radically simple. Local files similar to SQLite, but custom compression. The database gets synchronised using HTTP (nginx+sendfile) to different satellite nodes on different continents using cheap disposable VMs.
The Open-Meteo API exceeds 50 million calls per day. I am sceptical it will be economic to run a free weather API with a large AWS stack.