Laravel Yr Laravel Package

Product Decisions This Supports

• Weather-dependent feature bets. The package covers three distinct data shapes — location forecasts, short-horizon nowcasts (precipitation in the next hour or two), and sun/moon times — which map to three different product surfaces: daily planning UI, "rain in 20 minutes" minute-level prompts, and quiet-hours / daylight-aware scheduling and notifications. Roadmap items in outdoor, mobility, logistics, agriculture, energy, events, and retail footfall all hinge on the same underlying forecast call, so this is a shared platform capability rather than a single feature.
• Build vs. buy, leaning build. The upstream source is MET Norway (yr.no): free, no API key, no per-call cost, no contract. The build cost being replaced here is not the HTTP call — it is the caching and revalidation layer. v1.2.1 is almost entirely about that layer, which is precisely the part teams underestimate when they say "it's just a GET request."
• Freshness SLAs you can put in a spec. Before this release, Cache::remember() overwrote MET's Expires header with cache_ttl, meaning the app's data was fresher or staler than MET intended, by configuration accident. After this release the cache lifetime is governed by MET's own Expires (floored at 60 s), with cache_ttl / nowcast_cache_ttl as fallback only. Product can now state a defensible promise — "forecast data is no older than MET's stated expiry" — instead of a number someone guessed in a config file.
• Upstream-politeness as a product risk, now mitigated. Third-party terms compliance and rate-limit headroom are the classic hidden failure mode of free weather APIs: a marketing push or a viral day multiplies calls, the upstream throttles or blocks, and the feature degrades in production. Honouring Expires, keeping the last good answer for a day, revalidating with If-Modified-Since, and reusing a 304 body all cut origin traffic while improving data quality — a rare both-directions win.
• Degraded-state design is now an explicit decision, not an accident. A non-JSON body returns null instead of throwing, and failed requests are never cached. That converts a crash into a UI state you own: empty, last-known, hidden module, or a fallback provider. Someone has to decide which, per surface.
• Safe upgrade, no roadmap tax. No public API changes means this ships as a dependency bump inside routine maintenance — no migration story, no design review, no user-facing changelog entry. It closes a correctness bug without consuming roadmap capacity.
• Attribution is a product and legal decision, not an implementation detail. MET Norway data carries a credit requirement and an identifying-User-Agent expectation. That means a visible "Weather data from MET Norway" affordance, an app-store privacy/attribution line, and a configured identity string — all of which need an owner before launch, not after.

When to Consider This Package

Consider it when most of the following hold:

• You are on Laravel (verified against Laravel 10 / Carbon 2 in this release) and want the weather integration to be a composer dependency rather than a bespoke service class.
• Your users are in MET's strong coverage area — the Nordics and Europe generally, where yr.no is a credible, locally trusted brand. Trust transfers to your product.
• You need forecast, nowcast, and/or sun/moon from one source and would rather not stitch three vendors together.
• You want zero vendor cost and zero procurement. Free, keyless, no contract to route through legal.
• Your freshness tolerance is measured in minutes to hours, not seconds. This is consumer weather, not a trading signal.
• You can absorb the operational obligations: honouring attribution, sending an identifying User-Agent, and accepting a free service's absence of SLA.
• You are willing to own the degraded path. Because non-JSON yields null and failures are never cached, you need a defined behaviour for "no data right now" — banner, stale-with-timestamp, or hide the module.

Look elsewhere when:

• You need contractual uptime, indemnity, or support. A free national-met-service API gives you none of that. If weather drives revenue-critical decisions (insurance pricing, flight ops, energy trading), you need a commercial provider with an SLA.
• You need historical or climate data, or an archive you can query. This is a current-conditions and forecast wrapper; backtesting and trend analysis are out of scope.
• You need severe-weather alerting as a first-class product surface. Warnings are a separate MET offering with their own integration and severity semantics; don't assume they arrive through a forecast payload.
• Your audience is outside Europe and forecast quality matters more than cost. MET's global coverage exists but degrades outside its home region; a regional provider will beat it for US, Japan, or tropical hyperlocal use cases.
• You need multi-source blending or ensemble confidence intervals. A single-upstream wrapper gives you one deterministic answer, not a probability distribution.
• You need a guaranteed-typed error model. null on malformed bodies is a deliberate, forgiving contract. If you want exceptions and typed failures to drive retries and alerting, wrap it or pick something stricter.
• You need on-device or offline operation, or per-request latency budgets under a few hundred milliseconds without a warm cache.

How to Pitch It (Stakeholders)

To executives — one paragraph. We can add weather-aware features without a vendor contract, an API key, or a procurement cycle, because the upstream data is free from MET Norway, the same source behind yr.no. This release is a reliability fix, not a feature release: the package now respects the data provider's own cache-expiry instructions instead of overriding them with our settings, keeps serving the last good forecast when the upstream is unreachable, revalidates cheaply instead of re-downloading, and never caches a failed response. Net effect: fresher data, fewer upstream calls, no stale-error lockouts, and no engineering sprint required to adopt it. The trade-off we accept is that a free public service offers no uptime guarantee, so we design the UI to degrade gracefully and we credit MET Norway as their terms require.

To engineering — the ask. Upgrade to v1.2.1 as a routine dependency bump: there are no public API changes, so nothing in our integration code needs to move. What does need a decision is the surrounding behaviour. First, confirm our configured cache_ttl and nowcast_cache_ttl are now understood as fallbacks for when MET omits Expires, not as the primary control — if anyone tuned those values to force refresh behaviour, that tuning is now inert and should be deleted rather than left as misleading config. Second, since a non-JSON body returns null and failures are never cached, verify each call site has an explicit null handler: last-known-value with a timestamp, a hidden module, or a fallback source. Third, confirm the client sends an identifying User-Agent, since that is an upstream expectation and our politeness budget depends on it. Fourth, the 304 path keeps a body for a day and reuses it until the new Expires — worth a cache-key review to make sure no per-user variation is accidentally sharing an entry.

To design and content. Nowcast unlocks short-horizon copy that forecasts cannot support ("rain starting in about 20 minutes"), and sun/moon times unlock daylight-aware scheduling and notification quiet hours. Both need a defined empty state, because the package will hand you null rather than an exception when upstream returns something unexpected. Attribution placement should be settled now, while the surfaces are still being drawn.

What this is not. It is not a weather-alerting system, not a historical archive, and not an SLA-backed vendor relationship. If any of those become requirements, that is a new sourcing conversation, not a config change.