Laravel Yr Laravel Package

Technical Evaluation

Architecture fit: The package remains a thin, framework-native integration around MET Norway's Locationforecast/Nowcast APIs, sitting cleanly in Laravel's cache, HTTP client, and config layers. v1.2.1 does not alter that shape; it corrects the caching contract so the package now respects the upstream provider's freshness signals rather than its own static TTL. That is architecturally the right call — caching lifetime is owned by MET, and the package now defers to it.

Integration feasibility: No public API changes, no config keys added or removed, no migration required. Existing consumers calling the forecast/nowcast/sun-moon methods see identical signatures. The behavioural deltas are all in edge-case handling (expired Expires, 304 responses, non-JSON bodies, failed requests), which most integrations will experience as improved correctness rather than different results. Integration effort for an existing adopter is a composer bump and a regression pass.

Technical risk: Low but non-zero, and concentrated in three areas:

• Cache lifetime behaviour change. Teams that deliberately set a long cache_ttl to reduce upstream calls will now get MET's Expires (often 30–60 min for forecasts, shorter for nowcast) instead. Effective cache hit rates and outbound request volume will change — generally downward in freshness lag, upward in request count. Anyone rate-limiting against MET should re-measure.
• The 304 path. Retaining the last good body for a day and revalidating with If-Modified-Since introduces stateful behaviour that previously didn't exist. It's a resilience improvement, but it means a stale-but-valid forecast can be served for up to 24 h if MET keeps returning 304. Acceptable for weather; worth confirming it's acceptable for the consumers' display requirements.
• Silent null on non-JSON. Returning null instead of throwing is more forgiving but shifts failure detection to the caller. Teams relying on exceptions for alerting need to check for null explicitly.

Key questions:

• Does any downstream consumer depend on a cache_ttl longer than MET's Expires (e.g. to cap outbound calls)?
• Is a 24 h retention window for a last-good body acceptable for the product's freshness SLA, particularly for nowcast (which is short-horizon by nature)?
• Do callers currently distinguish "no data" from "failed request"? The null-on-non-JSON change makes that distinction the caller's responsibility.
• Is the MET Expires floor of 60 s compatible with any tight polling loops?
• What is the support posture for Laravel 10 / Carbon 2, given the release explicitly patches that combination?

Integration Approach

Stack fit: Unchanged — Laravel 10+ with the framework HTTP client and cache store, no new dependencies, no service provider or facade changes. It fits the same slot in the architecture as before: a cached read-through adapter to an external forecast API.

Migration path: Composer update to ^1.2.1. No code changes required for correctness. The only deliberate action item is auditing any place where cache_ttl / nowcast_cache_ttl were tuned as a cost or rate-limit control rather than a freshness control — those settings are now advisory fallbacks, not overrides.

Compatibility: No breaking changes to the public API or config surface. The Laravel 10 / Carbon 2 Expires-in-the-past fix removes a latent bug on that combination (previously a past timestamp produced a TTL equal to the full negative offset rather than the 60 s floor). No PHP version or dependency constraint changes are implied by the notes.

Sequencing:

1. Bump the dependency in a non-production branch and run the existing test suite; add coverage for null returns and 304 handling if not present.
2. Instrument outbound request counts to MET before and after in staging, specifically for nowcast, to quantify the TTL change.
3. Confirm caller-side handling of null (non-JSON and failure cases).
4. Roll out to production; monitor error rates and MET request volume for one full forecast refresh cycle (≥24 h) to observe the 304 path in practice.
5. Revisit any cache_ttl values that were set for rate-limiting reasons and move that control to an explicit layer if still needed.

Operational Impact

Maintenance: Negligible ongoing cost. This is a bug-fix release with no deprecations and no expansion of the public surface, so the maintenance burden is unchanged. Style-only Pint churn does not affect consumers. The package still tracks an external, unversioned government API, which remains the principal long-term maintenance exposure regardless of this release.

Support: The fixes reduce the most common support categories — stale-then-null data, cached failures, crashes on non-JSON error pages, and Carbon 2 TTL oddities. Expect fewer "why is my forecast null" tickets and more "why are we calling MET more often" questions during the transition. Document the new caching semantics (MET Expires wins, 60 s floor, 24 h last-good retention) in the team's internal notes, as the previous behaviour is likely baked into assumptions.

Scaling: Slightly higher outbound request volume under load if prior configs used long TTLs; the 304 revalidation path partially offsets this by avoiding full body transfers. The 60 s floor bounds the worst case for pathological Expires values. No new memory or storage pressure beyond retaining one body per cache key for up to a day.

Failure modes:

• MET returns 304 indefinitely → stale forecast served up to 24 h. Detectable by timestamp inspection, not by exception.
• MET returns non-JSON (e.g. HTML error page) → null returned silently; callers must handle. Log/alert on null rate.
• MET returns Expires in the past → cached 60 s (bounded, safe).
• Upstream failure → not cached, so next call retries; good, but means a sustained outage produces sustained retry traffic — retain existing circuit-breaking or backoff at the caller if present.
• Cache store unavailable → unchanged from prior behaviour; the package does not degrade gracefully on cache failure.

Ramp-up: Very low. No new concepts for a developer already familiar with the package; the only learning is the caching contract (MET-owned TTL, 304 revalidation, null on invalid body). A short note in the team wiki plus the two or three edge cases above is sufficient — call it under an hour for an experienced Laravel developer, plus the staging measurement exercise if outbound volume matters.