Freecodecamp: FCC Weather API随机返回日本天气

我想我已经确定了问题！ 它只是从包含日语数据

仅当队列中有60个以上的请求时才使用高速缓存（第50行）。这意味着_sometimes_它会返回正确的结果； 但是_sometimes_会返回这些意外的结果。

如何解决？ 我们有三种选择...

• 删除缓存
• 使缓存起作用，并在决定是否使用缓存时实际使用纬度和经度数据。
  
  
  
  • 如果服务器感到超载，则完全拒绝该请求（目前建议）
  
  

由于需要帮助，因此我很乐意对此进行研究。 但是，鉴于这是如何破坏项目的，并且鉴于我需要睡眠，如果有人想解决此问题（最简单的方法是更改​​缓存以改为拒绝请求），那么请这样做！

好吧，我想我已解决了这个问题。 不过，我无法测试它，因为我缺少API密钥-当然，由于我们从不使用缓存，因此存在DOS的风险。

因此，可以进行改进。 也许我们应该拒绝发送日文数据的请求吗？ 这取决于你们。 我暂时修复它，明天我将努力使它变得更好。

我认为我无法向glitch.me API发出请求请求（当然，除非我错过了GitHub上的存储库）； 因此具有写许可权的人在使用有效的API密钥对其进行测试后，需要将我的更改合并。

是的，我现在很生气。 但我意识到速率限制是必需的。 我将尽快修复我的代码，以便在进行过多的API调用时拒绝请求。

好的，我现在想我已经在短期内创建了一个解决方案。 我不确定我们如何处理可怕的数据收集-坐标往往非常精确（我们是否应该将它们四舍五入以缓存钱包？）。 如果它们来自缓存，我们一定要对其进行标记，以使其不是100％准确。

无论如何，就目前而言，无论何时代码尝试访问缓存，它都会发送一条错误消息。

 function getBestCachedData(lon, lat){
+ /*
   var fs = require('fs');
   var obj = JSON.parse(fs.readFileSync('./data/cache.json', 'utf8'));
+ */
-  return obj;
+  return {
+     "error": "This API is overloaded with requests at the moment. Please try again in a few seconds and see if you get a response"
+  }
  }

嗨， @ joker314，我同意您的拒绝错误的解决方案。 你能做一个公关吗？ 非常感谢您抽出宝贵的时间对此进行调查。

@QuincyLarson您能否指导谁可以访问此https://fcc-weather-api.glitch.me/ ？ 如果您是所有者，可以委托我。

@raisedadead，我很乐意，但是我环顾四周，我不确定glitch.me是否真的支持拉取请求-除非您在GitHub上也有一个副本，或者我缺少什么？

编辑：当然，可以在我的remix上找到更正的代码。

@ joker314是的，您是正确的，我们将从您的混音中更新项目。 请忽略我之前的评论。

我正在等待昆西确认是否可以访问该项目。 非常感谢您的帮助。

@raisedadead-那么此临时修复程序将

那么，此临时修复程序将持续多长时间？

这不会是暂时的，会出现错误，表明问题是由于速率限制所致。

这是在OpenWeatherMaps API之上创建的包装，我认为它不支持https，因此与Codepen冲突。

如果是这样，随着越来越多的露营者创建天气项目，情况只会变得更糟。 可以提高速率限制吗？

是的，您可以通过直接集成API而不是挑战中的故障包装器来选择付费版本。

参见https://openweathermap.org/price

@raisedadead看起来像原本打算用于缓存的代码。 如果是这样的话，并且如果我们可以弄清我们希望它尊重隐私的确切细节，那么希望我们可以解决速率限制问题吗？

经过深思熟虑，也许最好返回有效数据而不是错误消息。 让我们改为更改缓存以生成随机天气情况，然后将位置设置为“ API繁忙，请稍后再试以获得真实结果”？

@raisedadead，您对此有何想法？

作为刚刚完成此项目并遇到接收日本天气数据或（大部分时间）没有数据的问题的人，我想说接收任何数据比没有数据更有用。 至少通过日语数据，我可以看到我的代码是否有效，无论它显示的是准确的天气如何。

从理论上讲，我们可以发送随机数据。 但是我们不想因为数据不正确而受到投诉。我敢肯定这是一个例子。

无论如何，如果有帮助的话让我们拥有随机数据。

@QuincyLarson您可以指导上述要求吗？

我认为我们应该发送虚假数据，但要弄清楚它是虚假的。 将位置名称设置为“ API繁忙，伪数据”，并在响应中随机分配天气，坐标等。 这样，人们就知道为什么结果不准确。 但是一切仍然对开发人员有效。

有什么想法吗？

如果您发送虚假数据，我相信这会破坏为特定位置提供当前天气数据的全部目的。 我喜欢@ joker314的想法，即弄清楚我们如何创建和实现缓存。

请您考虑将最近的论坛讨论固定在项目页面上，以使编码人员知道该项目存在问题，并且不要花费不必要的时间来尝试解决他们无法控制的问题吗？

顺便说一句，我认为icon的图片网址未如https://fcc-weather-api.glitch.me/中所述返回
它说Images links are included in the JSON under weather[0].icon ，不是。
我注意到演示解决方案编写了CSS来绘制图标。

谢谢，让我们知道了这个潜在的问题，但是示例请求和响应确实包含所需的字段。 您提出了哪些没有此字段的特定请求？

@ joker314 Thx进行回复。

https://fcc-weather-api.glitch.me/api/current?lon=39.988&lat=116.3000

{"coord":{"lon":139,"lat":35},"weather":[{"id":803,"main":"Clouds","description":"broken clouds"}],"base":"stations","main":{"temp":28.23,"pressure":1011,"humidity":74,"temp_min":26,"temp_max":31},"visibility":10000,"wind":{"speed":3.6,"deg":230},"clouds":{"all":75},"dt":1499396400,"sys":{"type":1,"id":7616,"message":0.0043,"country":"JP","sunrise":1499369792,"sunset":1499421666},"id":1851632,"name":"Shuzenji","cod":200}

我没有注意到示例运行良好，所以我想这可能是由于位置或特殊天气造成的吗？

@ Em-Ant看来这是在Glitch上运行的应用程序的问题。 您能否看一下缓存，看看是否可以清除？

我做了一些快速测试，我相信这是固定的。 如果仍有问题，请随时重新打开此问题。

@ moT01您做了什么样的测试？ 问题是，每个免费的FCC帐户都有一个速率限制，用于拨打OpenWeather API。 一旦达到这些速率限制，小故障代理就会返回日本坐标。 现在不被视为问题的唯一原因是，该项目现在在课程表中是可选的，因此，它所受到的打击没有以前那么多了。 您在一分钟内击中小故障60次后，将返回以下JSON：

{
  "coord": {
    "lon": 139,
    "lat": 35
  },
  "weather": [
    {
      "id": 803,
      "main": "Clouds",
      "description": "broken clouds"
    }
  ],
  "base": "stations",
  "main": {
    "temp": 28.23,
    "pressure": 1011,
    "humidity": 74,
    "temp_min": 26,
    "temp_max": 31
  },
  "visibility": 10000,
  "wind": {
    "speed": 3.6,
    "deg": 230
  },
  "clouds": {
    "all": 75
  },
  "dt": 1499396400,
  "sys": {
    "type": 1,
    "id": 7616,
    "message": 0.0043,
    "country": "JP",
    "sunrise": 1499369792,
    "sunset": 1499421666
  },
  "id": 1851632,
  "name": "Shuzenji",
  "cod": 200
}

您是否可以重新打开此问题，因为它仍在我要解决的项目任务列表中？

嗯，是的-我刚刚对api进行了几次快速调用，就能获得正确的天气。 我想我可能应该在解决问题之前先咨询一些。

我从Hacktoberfest开始就着手进行修复，然后大量参与了质量检查流程。 剩下的就是历史了。 我需要再次回顾一下，因为现在我对Node和Express有了更好的理解，从而能够获得可行的解决方案。

静态缓存只有一个条目（在日本的位置）。

我们可以修复它，删除速率限制器（我不知道这是否是个好主意，因为那里只有一个api键），或者在超出请求配额的情况下返回速率限制错误。

无论如何，这个在glitch上的api项目归@MiloATH拥有，

我已使用camperbot帐户在https://glitch.com/edit/#!/fcc -weather-api上向Milo发送了加入请求。

听起来不错！ 还有第三种选择。 修复缓存，以便将数据实际存储在该缓存中；如果命中了限速器，则发送随机数据。

我担心超出速率限制不是一个好主意，因为在这种情况下，API密钥可能会被吊销，并且在任何情况下我们都可能无法从API获得结果。

@ joker314我已经朝着您的第三个选择迈进了。

我已将邀请发送给故障项目。

端点可能会更好。 我认为我们应该使用CI构建单独的存储库，并部署到更成熟的版本（例如Heroku）（免费版本）。 这将使我们能够更轻松地从事该项目。

我们不会再部署到heroku了。 我们现在将使用Glitch。 意味着如果有其他项目，我们很乐意将其部署在Glitch上的freeCodeCamp帐户下，并替换课程中现有的挑战

@raisedadead @RandellDawson
嗨！ 有任何更新吗？
看到一些带有架构和数据流的图表（以及最终关联的文件名）真是太棒了

@ Hash2C您可以重新混合现有的Glitch项目（如下所示）以查看并修复该项目。

https://glitch.com/edit/#!/fcc -weather-api？path = server.js：1：0

感谢@RandellDawson ，我一直在努力，希望我能在周四之前完成初稿。

@ Hash2C花点时间做对。 这个错误已经存在了很长时间。

谢谢@RandellDawson ，我会努力的。
我将需要更多地了解当前的约束。
我在上面读到，我们限制每分钟60次点击，这似乎是OpenWeather定价中的免费套餐。 有没有办法增加这个限制？ 喜欢创建其他OW订阅吗？ 我们可以和OW一起使用其他免费的“真理来源”吗？

编辑：此外，什么样的延迟是可以接受的？ 5分钟？ 15分钟？ 1小时？ 3小时？

Edit2：如表所示，OW“天气API数据更新”似乎为“ <2小时”
https://openweathermap.org/price
同一张表告诉我们，可用性只有95％

有没有办法增加这个限制？ 喜欢创建其他OW订阅吗？

他们可能也对IP地址有限制（不确定），因此创建其他订阅将无济于事。

我们可以和OW一起使用其他免费的“真理来源”吗？

不确定。

Edit2：如表所示，OW“天气API数据更新”似乎为“ <2小时”

我目前正在使用OpenWeather的免费版本开发自己的天气项目，并且考虑仅检查请求是否比上次请求少于10分钟，然后显示相同纬度/经度的最后返回数据。

我认为我们也可以更新挑战说明，以使开发人员知道如果达到限制，我们将发回特殊答复，以便他们可以让应用程序用户知道数据可能不是最新的。 我们仍然希望返回与当前相同的数据（以免使用FCC API破坏任何旧项目）。 我们只会在响应中添加一个额外的属性。 你怎么看？

我创建了此存储库，以便在本地进行测试更加容易。
https://github.com/Hash2C/fccWeatherApiDraft

我认为（目前）已经涵盖了3个主要用例

• 如果坐标无效/不正确，请发送错误
  否则，将坐标转换为方便的格式，然后我们尝试命中缓存

• 如果请求的坐标被缓存
  
  
  
  • 如果时间戳在可接受的增量之内：发送缓存的数据（1）
  
  
  • 否则：将模拟数据设置为缓存数据（以防以后的OpenWeather api调用失败）
  
  

• 否则：将模拟数据设置为我们决定的方式（以防以后的OpenWeather api调用失败）。

• 我们尝试调用OpenWeather api。

• 如果我们获得正确的数据，则将其发送并存储在缓存中（2）
• 否则，发送模拟数据（3）

当然，这种流程非常开放！

仍有大量工作要做，包括验证，异步工作，边缘案例（测试）等，但我们将逐步实现。 我对server.js文件进行了很多评论（不要害怕），我将逐步过滤掉大部分信息，并在这里向您寻求帮助，以便我们讨论每个问题。

只是一个想法：我们最终能否拥有一个数据服务，该服务试图将“未发出的对OpenWeather API（或其他）的可用请求”的数量减至最少？ 假设该服务将提供一个MongoDB数据库-这将是我们的缓存（我们可以使用Memcached，但这可能太多了，我们不需要额外的速度）

其他想法：该服务过去是否有使用情况统计信息？ 如果没有，也许我们可以开始创建一个，也许可能有用，以尝试优化最终可能但非常不理想的解决方案

我肯定需要帮助才能了解的一件事是，此安全问题github警告我有关

（由于某种原因，我完全错过了您的留言！）

他们可能也对IP地址有限制（不确定），因此创建其他订阅将无济于事。

好点子。 值得测试吗？

我们可以和OW一起使用其他免费的“真理来源”吗？

不确定。

如果允许我们这样做，可能会大大增加获得成功解决方案的可能性。

我目前正在使用OpenWeather的免费版本开发自己的天气项目，并且考虑仅检查请求是否比上次请求少于10分钟，然后显示相同纬度/经度的最后返回数据。

是的，使用缓存的数据对吗？ 我提出了<2小时的问题，因为我之前曾问过可接受的延迟。 延迟时间越长，效果越好，因此我们可以更多地访问缓存，而不必经常调用api。 假设我们可以开始发送最多1小时的数据，则开始编码。

我认为我们也可以更新挑战说明，以使开发人员知道如果达到限制，我们将发回特殊答复，以便他们可以让应用程序用户知道数据可能不是最新的。 我们仍然希望返回与当前相同的数据（以免使用FCC API破坏任何旧项目）。 我们只会在响应中添加一个额外的属性。 你怎么看？

我完全同意向开发人员提供相关信息并让他们选择的想法，这也是我考虑的最合适的方法

在FCC项目中是否有用于测试和发出请求的标准工具？
对于我正在使用的请求（只是因为我决定尝试一下，而不是Axios）
www.npmjs.com/package/request
对于测试，我没有太多经验，但是我在考虑Mocha。
但是，请让我知道哪些工具可以更好地与FCC集成

我肯定需要帮助才能了解的一件事是，此安全问题github警告我有关

最简单的解决方案是运行npm audit fix ，然后提交更新的package.json和package-lock.json 。 与以前的易受攻击软件包相比，新软件包不应有重大更改。 但是，这是假定软件包作者没有意外引入重大更改，因此值得在应用修补程序后手动检查您的应用程序。

我一直在使用OpenWeather api（实际上我应该从一开始就应该这样做）。
我们知道吗？ https://openweathermap.org/faq#error401
相关部分

对于FOSS开发人员：我们欢迎免费和开源软件，并愿意为您提供帮助。 如果要在免费软件应用程序中使用OWM数据，请注册一个API密钥并提交一张票证，描述您的应用程序和已注册的API密钥。 如果在开源应用程序中使用，OWM将检查您的密钥请求电梯访问限制。

大家好，我的约束比预期的要多。
在业余时间，我一直在研究OpenWeather api。 不幸的是，它没有很好的记录。
我想我使用bbox选项提出了可行的策略，但我仍在测试中。
我想到了使用所有遇到的信息，正在执行的测试来创建文档的想法。

@ Hash2C花点时间做对。 这个错误已经存在了很长时间。

@兰德尔道森
您知道您在说什么：heavy_check_mark：

@ Hash2C您的解决方案

由于从事该项目的用户数量总体上已大大减少，因此结束了该问题，因为它不再是认证所需的项目。 这导致达到API速率限制的实例更少。