Freecodecamp: FCC Weather API случайным образом возвращает погоду в Японии

Я думаю, что обнаружил проблему! Это просто чтение из кеша , который содержит японские данные.

Кэш используется только в том случае, если в его очереди более шестидесяти запросов (строка 50). Это означает, что _ иногда_ он будет возвращать правильные результаты; но _ иногда_ он возвращает эти неожиданные результаты.

Как это исправить? У нас есть три варианта ...

• Удалить кеш
• Сделайте кеш функциональным и фактически используйте данные широты и долготы при принятии решения, использовать ли кеш.
  
  
  
  • Полностью отклонить запрос, если сервер чувствует себя перегруженным ( сейчас рекомендуется )
  
  

Поскольку мне нужна помощь, я хотел бы взглянуть на это; однако, учитывая, насколько это мешает проектам, и учитывая, что мне нужно спать, если кто-то хочет это исправить (самый простой способ - изменить кеш, чтобы вместо этого отклонять запросы), сделайте это!

Хорошо, я думаю, что решил проблему . Однако я не мог проверить это, потому что у меня не было ключа API - и, конечно, есть риск DOS, учитывая, что мы никогда не прибегаем к кешированию.

Итак, улучшения могут быть сделаны. Может быть, мы должны отклонять запросы, если в противном случае мы отправляли бы японские данные? Это зависит от вас. Я исправлю это временно, и я постараюсь улучшить его завтра.

Не думаю, что смогу сделать запрос на перенос к API glitch.me (если, конечно, на 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 или я что-то упускаю?

РЕДАКТИРОВАТЬ: Конечно, исправленный код можно найти в моем ремиксе .

@ joker314 да вы правы, мы обновим проект с вашего ремикса. Пожалуйста, проигнорируйте мой предыдущий комментарий.

Я жду от Куинси подтверждения доступа к этому проекту. Большое спасибо за вашу помощь с этим.

@raisedadead - Как долго будет действовать это временное исправление? Каким будет окончательное решение для этого? Это просто проблема с ограничением скорости? Если так, то ситуация будет только ухудшаться, поскольку все больше отдыхающих создают погодные проекты. Можно ли увеличить лимит скорости?

Итак, как долго будет действовать это временное исправление?

Это не будет временным явлением, при ошибке будет известно, что проблема связана с ограничениями скорости.

Это была оболочка, созданная поверх OpenWeatherMaps API, которая, как мне кажется, не поддерживала https и, следовательно, конфликтовала с codepen.

Если так, то ситуация будет только ухудшаться, поскольку все больше отдыхающих создают погодные проекты. Можно ли увеличить лимит скорости?

Да, вы можете выбрать платную версию, интегрировав API напрямую вместо обертки с ошибками в задаче.

См. Https://openweathermap.org/price

@raisedadead Похоже, исходный код предназначен для кеширования. Если это так, и если мы можем сгладить детали относительно того, как именно мы хотим, чтобы это выглядело, чтобы уважать конфиденциальность, то, надеюсь, мы сможем обойти ограничение скорости?

Поразмыслив, возможно, лучше вернуть действительные данные вместо сообщения об ошибке. Вместо этого давайте изменим кеш для генерации случайных погодных условий и установим местоположение на «API занят, попробуйте еще раз позже для реальных результатов»?

Что ты думаешь по этому поводу, @raisedadead?

Как человек, только что завершивший этот проект и столкнувшийся с проблемой получения данных о погоде в Японии или (в большинстве случаев) отсутствия данных, я хотел бы сказать, что получение любых данных более полезно, чем их отсутствие. По крайней мере, с японскими данными я мог видеть, работает ли мой код, независимо от того, показывает ли он точную погоду.

Теоретически мы могли отправлять случайные данные. Но мы не хотим получать жалобы на неверные данные ... что, я почти уверен, будет.

В любом случае, если это поможет, пусть будут случайные данные.

@QuincyLarson, не могли бы вы помочь с указанным выше запросом ?

Я думаю, нам следует отправлять фальшивые данные, но дать понять, что это фальшивка. В качестве названия местоположения укажите "API Занят, Поддельные данные", а в ответе случайным образом должны быть указаны погода, координаты и т. Д. Таким образом, люди знают, почему результаты неточны; и все же для разработчиков все будет работать.

Мысли?

Если вы отправите поддельные данные, я считаю, что это лишит вас всей цели предоставления текущих данных о погоде для определенного места. Мне нравится идея @ joker314 о том, как мы хотим создать кеш и реализовать его.

Не могли бы вы закрепить недавние обсуждения на форуме на странице проекта, чтобы программисты знали о проблемах с проектом и не тратили ненужное время, пытаясь исправить то, что они не могут контролировать?

Кстати, я думаю, что URL-адрес изображения icon не возвращается, как описано в https://fcc-weather-api.glitch.me/.
Там написано Images links are included in the JSON under weather[0].icon , но это не так.
Я заметил, что демонстрационное решение написало css для рисования значка.

Спасибо, что сообщили нам об этой потенциальной проблеме, но пример запроса и ответа действительно включает нужное поле. Какой конкретный запрос вы сделали, не имея этого поля?

@ joker314 Спасибо за ответ.

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, используемой для вызовов API OpenWeather. Как только эти ограничения скорости достигнуты, прокси-сервер Glitch возвращает координаты Японии. Единственная причина, по которой сейчас это не рассматривается как проблема, заключается в том, что этот проект теперь является необязательным в учебной программе, поэтому сейчас к нему не так много обращений, как раньше. Как только вы нажимаете Glitch 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 и смог узнать точную погоду. Я полагаю, мне, вероятно, следует узнать немного больше, прежде чем закрывать вопросы.

Я начал работать над исправлением в самом начале Хактоберфеста, а затем активно включился в процесс контроля качества. Остальное уже история. Мне нужно вернуться к этому еще раз, потому что теперь я гораздо лучше понимаю Node и Express, чтобы иметь возможность запустить рабочее решение.

Есть статический кеш, в котором есть только одна запись (местоположение в Японии).

Мы могли бы исправить это, удалив ограничитель скорости (я не знаю, хорошая ли это идея, поскольку у нас есть только один ключ api), или вернуть ошибку ограничения скорости в случае превышения квоты запросов.

В любом случае, этот api-проект с ошибкой принадлежит

Я отправил Майло запрос на присоединение на https://glitch.com/edit/#!/fcc -weather-api, используя учетную запись camperbot.

Это похоже на хорошие идеи! Есть третий вариант; для исправления кеша, чтобы данные действительно хранились там, или для отправки случайных данных, если сработает ограничитель скорости.

Боюсь, что превышение предела скорости - не лучшая идея, поскольку в таких обстоятельствах ключ API может быть отозван, и в любом случае мы не сможем получить результаты от API.

@ joker314 Я уже двигался в сторону вашего третьего варианта.

Я передал приглашение в глюк-проект.

Конечная точка могла бы быть значительно лучше. Я думаю, мы должны создать отдельное репо с CI и развернуть его на более зрелом уровне вроде Heroku (бесплатная версия). Это позволит нам упростить работу над проектом.

Мы больше не отправляемся на героку. Пока мы будем использовать Glitch. Это означает, что если есть альтернативный проект, мы будем рады развернуть его под учетной записью freeCodeCamp на Glitch и заменить существующую задачу в учебной программе.

@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)
  
  
  • else: установить фиктивные данные как кэшированные (на случай, если позже вызов API OpenWeather не удастся)
  
  

• else: установить фиктивные данные как то, что мы решаем (на случай, если позже вызов API OpenWeather не удастся).

• Пробуем вызвать 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 . В новых пакетах не должно быть никаких критических изменений по сравнению с предыдущими уязвимыми. Однако предполагается, что авторы пакета не случайно внесли критическое изменение, поэтому стоит вручную проверить приложение после применения исправлений.

Я играл с API OpenWeather (на самом деле я должен был сделать это с самого начала).
Знали ли мы об этом? https://openweathermap.org/faq#error401
Соответствующая часть

Для разработчиков FOSS: мы приветствуем бесплатное программное обеспечение с открытым исходным кодом и готовы помочь вам. Если вы хотите использовать данные OWM в своем бесплатном программном приложении, зарегистрируйте ключ API и отправьте заявку с описанием вашего приложения и зарегистрированного ключа API. OWM рассмотрит ваш запрос на снятие ограничений доступа для вашего ключа, если он используется в приложении с открытым исходным кодом.

Привет, ребята, я был более скован, чем ожидал.
В свободное время изучаю API OpenWeather. К сожалению, это плохо документировано.
Я думаю, что придумал реальную стратегию, используя опцию bbox, но я все еще тестирую.
Мне пришла в голову идея создать документ со всей информацией, с которой я столкнулся, и с тестами, которые я выполняю.

@ Hash2C Не торопитесь, чтобы понять это правильно. Эта ошибка существует довольно давно.

@RandellDawson
Вы знали, о чем говорите: heavy_check_mark:

@ Hash2C Как

Закрытие этой проблемы, поскольку количество пользователей, работающих над этим проектом в целом, значительно сократилось, поскольку он больше не является обязательным проектом для сертификации. Это привело к меньшему количеству случаев, когда достигается предел скорости для API.