Friday, May 9th 2025, 4:42 pm
We have already built a great variety of forecast, METAR, and location-based forecasts feeds that consume the Baron Velocity Weather API. Not only that, but the way we built that integration is a separate auto-scaling "task runner" or microservice. What that means for you, is that your weather page, or any features that require real-time forecast data will not crash during a significant weather event.
PDEs (Potentially Dangerous Events) are become more common these days. They occur in areas where nobody could have expected, and often in locations where the weather authorities and forecasters are not technically equipped to deal with the sheer amount of views they are likely to get. Consider Superstorm Sandy, or Hurricane Helene. These are not areas where the is frequently large and life threatening weather events. If your affiliate is not prepared to deal with millions of eyes suddenly turning to your website and app, and the subsequent pressure that puts on your national forecast provider, you are sunk. Page render failures, app failures, livestream failures can be a direct threat to human life in those circumstances.
Viking CMS was forged in the Oklahoma Storm Season. We know how bad it can get. We know how to deal with extraordinary, and sudden shifts in traffic patterns. The point is, even our Baron Task Runner scales. While the primary auto-scaling group for the CMS is scaling to 20 or more individual servers, we've also seen our Baron Task Runner scale to three or more instances. This is incredibly important because it's not just the views during PDEs, it's the interactions. Perhaps you have 50,000 concurrent users during an extreme event, and most of them are checking METAR, forecasts, and NOAA weather alerts for their geolocation? That loads the Baron API, but with our Baron Task Runner, a caching layer prevents any duplicate requests from falling on to Baron. This not only increases your capabilities, but also reduces your costs, because you are paying for the Baron Velocity API, not us. We use your secret keys, and we use them wisely, with concern for your users, and your budget!
We know there are other forecast providers, and if you would prefer to use a different one, we can, and we would build it using the same thoughtful framework.
I'm Don Drury, and I created Viking CMS. I built a whole enterprise-scale CMS based on a need I saw working as a front-end developer within the largest media conglomerate in Oklahoma. They had spent 20 years trying to work around their CMS. They had hired a back-end developer, a front-end developer, 4 designers and still weren't able to do the basic things they wanted to do. I built Viking CMS and changed everything for them.
2 Months Ago
2 Months Ago
2 Months Ago
2 Months Ago