为什么我在 Firefox 扩展中使用 wttr.in 而不是 OpenWeatherMap

Source: Dev.to

请提供您希望翻译的完整文本内容，我将按照要求保留源链接、格式和代码块，仅翻译正文部分为简体中文。

API 选项对比

摩擦差异

OpenWeatherMap 要求用户：

1. 创建账户
2. 生成 API 密钥
3. 将密钥粘贴到扩展设置中
4. 等待密钥激活（可能需要数小时）

wttr.in 只需要城市名称。去除这些步骤可显著提升从安装到活跃用户的转化率。

代码示例

wttr.in 请求（JavaScript）

// wttr.in request
const url = `https://wttr.in/${encodeURIComponent(city)}?format=j1`;

OpenWeatherMap 请求（JavaScript）

// OpenWeatherMap request
const url = `https://api.openweathermap.org/data/2.5/forecast?q=${encodeURIComponent(city)}&appid=${userApiKey}&units=metric`;

更简洁的代码意味着更少的错误。

wttr.in 示例响应

{
  "current_condition": [
    {
      "temp_C": "18",
      "weatherDesc": [{ "value": "Partly cloudy" }],
      "humidity": "65",
      "windspeedKmph": "20"
    }
  ],
  "weather": [
    {
      "date": "2024-01-15",
      "hourly": [{ "tempC": "15", "...": "..." }],
      "maxtempC": "22",
      "mintempC": "12"
    }
  ]
}

一次请求提供当前条件以及 3 天预报。

可靠性考虑

• 单一开发者项目 – 可能会宕机或在没有 SLA 的情况下施加速率限制。
• 速率限制 – 每 IP 限制可能会阻止高流量场景（例如，公司 NAT）。
• 数据来源 – wttr.in 从多个提供商聚合；不同地区的质量各异。
• 无付费层 – 不能提升限制或获得保证。

何时选择每项服务

对 wttr.in 的激进缓存

因为 wttr.in 没有付费层，我实现了客户端缓存以降低请求频率：

const CACHE_DURATION = 30 * 60 * 1000; // 30 minutes

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

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

  // Fetch fresh data
  const resp = await fetch(`https://wttr.in/${encodeURIComponent(city)}?format=j1`);
  const data = await resp.json();

  // Cache it
  await browser.storage.local.set({
    [cacheKey]: { data, timestamp: Date.now() }
  });

  return data;
}

这将 API 调用限制为 每位用户每 30 分钟一次，而不是在每次打开新标签页时都请求。

结论

Weather & Clock Dashboard 目前使用 wttr.in，能够很好地满足目标受众的需求。如果在大规模使用时出现可靠性问题，我计划将 OpenWeatherMap 添加为备用或主要选项。

在 Firefox 上安装扩展 – 源代码可在 GitHub 上获取。