Most weather widgets require API keys, rate limits, and sometimes credit cards. There's a better way

ere lightweight, reliable, and transparent data fetching is prioritized over enterprise SLAs.

Core Solution

The implementation leverages wttr.in's JSON API to deliver current conditions and a 3-day forecast without authentication. The architecture follows a fetch → parse → cache → render pipeline optimized for client-side execution.

JSON API Endpoint

https://wttr.in/London?format=j1

Returns a structured JSON payload containing current_condition, weather (3-day forecast), and nearest_area metadata. No API key or account required.

Data Parsing Pipeline

async function fetchWeather(location = '') {
  const url = `https://wttr.in/${encodeURIComponent(location)}?format=j1`;

  const response = await fetch(url);
  if (!response.ok) throw new Error(`Weather fetch failed: ${response.status}`);

  const data = await response.json();
  return parseWeatherData(data);
}

function parseWeatherData(data) {
  const current = data.current_condition[0];
  const today = data.weather[0];
  const tomorrow = data.weather[1];
  const dayAfter = data.weather[2];

  return {
    temperature: {
      c: parseInt(current.temp_C),
      f: parseInt(current.temp_F),
    },
    feelsLike: {
      c: parseInt(current.FeelsLikeC),
      f: parseInt(current.FeelsLikeF),
    },
    humidity: parseInt(current.humidity),
    description: current.weatherDesc[0].value,
    weatherCode: parseInt(current.weatherCode),
    forecast: [
      parseForecastDay(today),
      parseForecastDay(tomorrow),
      parseForecastDay(dayAfter),
    ],
    location: data.nearest_area[0],
  };
}

function parseForecastDay(day) {
  return {
    date: day.date,
    maxC: parseInt(day.maxtempC),
    minC: parseInt(day.mintempC),
    maxF: parseInt(day.maxtempC),
    minF: parseInt(day.mintempF),
    description: day.hourly[4]?.weatherDesc[0]?.value || '',
    weatherCode: parseInt(day.hourly[4]?.weatherCode || 0),
    sunrise: day.astronomy[0]?.sunrise || '',
    sunset: day.astronomy[0]?.sunset || '',
  };
}

Weather Code → Icon Mapping

wttr.in uses standard WMO weather interpretation codes. A deterministic mapping ensures consistent UI rendering:

function getWeatherIcon(code) {
  const icons = {
    113: '☀️',  // Sunny/Clear
    116: '⛅',  // Partly cloudy
    119: '☁️',  // Cloudy
    122: '☁️',  // Overcast
    143: '🌫️', // Mist
    176: '🌦️', // Patchy rain
    179: '🌨️', // Patchy snow
    182: '🌧️', // Patchy sleet
    185: '🌧️', // Patchy freezing drizzle
    200: '⛈️', // Thundery outbreaks
    227: '🌨️', // Blowing snow
    230: '❄️',  // Blizzard
    248: '🌫️', // Fog
    260: '🌫️', // Freezing fog
    263: '🌦️', // Light drizzle
    266: '🌧️', // Drizzle
    281: '🌧️', // Freezing drizzle
    284: '🌧️', // Heavy freezing drizzle
    293: '🌦️', // Light rain
    296: '🌧️', // Rain
    299: '🌧️', // Moderate rain
    302: '🌧️', // Heavy rain
    305: '🌧️', // Heavy rain at times
    308: '🌧️', // Very heavy rain
    311: '🌧️', // Light sleet
    314: '🌧️', // Sleet
    317: '🌨️', // Light snow/sleet
    320: '🌨️', // Moderate or heavy sleet
    323: '🌨️', // Light snow
    326: '🌨️', // Snow
    329: '❄️',  // Moderate snow
    332: '❄️',  // Heavy snow
    335: '❄️',  // Snow blowing
    338: '❄️',  // Heavy snow
    350: '🌧️', // Ice pellets
    353: '🌦️', // Light rain shower
    356: '🌧️', // Moderate or heavy rain shower
    359: '🌧️', // Torrential rain shower
    362: '🌨️', // Light sleet showers
    365: '🌨️', // Moderate or heavy sleet showers
    368: '🌨️', // Light snow showers
    371: '🌨️', // Moderate or heavy snow showers
    374: '🌨️', // Light showers of ice pellets
    377: '🌨️', // Moderate or heavy showers of ice pellets
    386: '⛈️', // Patchy light rain with thunder
    389: '⛈️', // Moderate or heavy rain with thunder
    392: '⛈️', // Patchy light snow with thunder
    395: '⛈️', // Moderate or heavy snow with thunder
  };
  return icons[code] || '🌡️';
}

Auto-Location Detection

Omitting the location parameter triggers IP-based geolocation:

// Auto-detect location
const weather = await fetchWeather('');
// or
const weather = await fetchWeather('auto');

Ideal for browser extensions where requests originate from the user's native IP.

Aggressive Caching Strategy

Weather data changes slowly. Client-side caching reduces network calls and improves perceived performance:

const CACHE_DURATION_MS = 10 * 60 * 1000; // 10 minutes

async function fetchWeatherCached(location = '') {
  const cacheKey = `weather_${location}`;
  const cached = await browser.storage.local.get(cacheKey);

  if (cached[cacheKey]) {
    const { data, timestamp } = cached[cacheKey];
    if (Date.now() - timestamp < CACHE_DURATION_MS) {
      return data; // Return cached data
    }
  }

  // Fetch fresh data
  const data = await fetchWeather(location);
  await browser.storage.local.set({
    [cacheKey]: { data, timestamp: Date.now() }
  });
  return data;
}

Resilient Error Handling

Graceful degradation ensures UI stability during network failures:

async function fetchWeatherSafe(location = '') {
  try {
    return await fetchWeatherCached(location);
  } catch (error) {
    console.warn('Weather fetch failed:', error);
    // Try to return stale cache rather than showing error
    const cacheKey = `weather_${location}`;
    const cached = await browser.storage.local.get(cacheKey);
    if (cached[cacheKey]) {
      return { ...cached[cacheKey].data, stale: true };
    }
    return null;
  }
}

Pitfall Guide

1. Ignoring Cache Staleness & TTL Boundaries: Weather data is inherently slow-changing. Failing to enforce a strict TTL (e.g., 10 minutes) causes unnecessary network requests and potential rate throttling. Always implement stale-while-revalidate patterns and mark cached responses as stale: true during fallbacks.
2. Skipping URL Encoding for Location Parameters: City names with spaces, accents, or special characters (e.g., São Paulo, New York) will break raw URL construction. Always wrap location inputs in encodeURIComponent() to prevent malformed requests and 400/404 responses.
3. Assuming "No Hard Rate Limit" Means Unlimited: While wttr.in lacks strict commercial caps, aggressive polling or unthrottled concurrent requests can trigger temporary IP blocks. Implement exponential backoff, respect Retry-After headers, and debounce rapid UI interactions.
4. Incomplete WMO Code Coverage: The weather code mapping spans 50+ states. Hardcoding only common codes leads to fallback icons (🌡️) during edge cases (e.g., freezing fog, ice pellets). Maintain a comprehensive mapping object and log unmapped codes for periodic updates.
5. Blocking the Main Thread with Synchronous Fetch: Using synchronous XMLHttpRequest or blocking event loops degrades extension performance. Always use async/await with fetch(), and offload heavy parsing to Web Workers if rendering complex dashboards.
6. Over-Reliance on IP-Based Geolocation: Auto-detection fails behind corporate NATs, VPNs, or proxy chains. Always provide a manual location override in the UI and store user preferences separately from auto-detected values.

Deliverables

• 📘 Integration Blueprint: Architecture diagram detailing the fetch → cache → parse → render pipeline, including browser extension storage boundaries, network request lifecycle, and fallback routing for stale data.
• ✅ Pre-Deployment Checklist: Validation matrix covering URL encoding verification, cache TTL configuration, WMO mapping completeness, error boundary testing, and main-thread non-blocking verification.
• ⚙️ Configuration Template: JSON-based config structure for location overrides, cache duration tuning, icon mapping extensions, and environment-specific endpoint routing (production vs. development).