Freecodecamp: FCC WeatherAPIがランダムに日本の天気を返す

私は問題を特定したと思います！ これは、日本のデータを含むキャッシュから読み取るだけです。

キャッシュは、キューに60を超えるリクエストがある場合にのみ使用されます（50行目）。つまり、正しい結果が返される場合があります。 しかし、_時々_これらの予期しない結果が返されます。

これはどのように修正できますか？ 3つのオプションがあります...

• キャッシュを削除します
• キャッシュを機能させ、キャッシュを使用するかどうかを決定するときに実際に緯度と経度のデータを使用します。
  
  
  
  • サーバーが過負荷になっていると感じた場合は、リクエストを完全に拒否します（今のところ推奨）
  
  

これは助けが必要なので、私はこれを見てみたいと思います。 ただし、これがプロジェクトを混乱させていることと、スリープが必要なことを考えると、誰かがこれを修正したい場合（最も簡単な方法は、代わりにリクエストを拒否するようにキャッシュを変更することです）、そうしてください！

さて、私は問題を

したがって、改善を行うことができます。 おそらく、日本のデータを送信するはずのリクエストを拒否する必要がありますか？ これはすべて次第です。 私はそれを一時的に修正し、明日それをより良くするために努力するつもりです。

glitch.me APIにプルリクエストを行うことはできないと思います（もちろん、GitHubに見逃したリポジトリがない限り）。 そのため、書き込み権限を持つ人は、有効なAPIキーでテストした後、変更をマージする必要があります。

そうです、私は現時点でafkです。 しかし、私は律速が必要であることに気づきました。 すぐにコードを修正して、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エラーで拒否するというあなたの解決策に同意します。 PRをお願いできますか？ これを調査するために時間を割いてくれてありがとう。

@QuincyLarsonは、このhttps://fcc-weather-api.glitch.me/にアクセスできるユーザーをガイドできますか？ あなたが所有者であれば、私は委任することができます。

@raisedadead見回したところ、glitch.meが実際にプルリクエストをサポートしているかどうかはわかりません-GitHubにコピーがあるか、何かが足りない場合を除きますか？

編集：もちろん、修正されたコードは私のリミックスで見つけることができます。

@ joker314はい、正解です。リミックスからプロジェクトを更新します。 以前のコメントは無視してください。

そのプロジェクトへのアクセスの確認をクインシーが待っています。 これを手伝ってくれてありがとう。

@ raisedadead-では、この一時的な修正はどのくらいの期間実施されますか？ これに対する究極の解決策はどのように見えるでしょうか？ これは単なるレート制限の問題ですか？ もしそうなら、より多くのキャンピングカーが気象プロジェクトを作成するにつれて、それはさらに悪化するでしょう。 レート制限を引き上げることはできますか？

では、この一時的な修正はどのくらいの期間実施されますか？

これは一時的なものではなく、エラーが発生すると、問題の原因がレート制限であることがわかります。

これはOpenWeatherMapsAPIの上に作成されたラッパーであり、httpsをサポートしていなかったため、codepenと競合していました。

もしそうなら、より多くのキャンピングカーが気象プロジェクトを作成するにつれて、それはさらに悪化するでしょう。 レート制限を引き上げることはできますか？

はい、チャレンジでグリッチラッパーの代わりにAPIを直接統合することで、有料バージョンを選択できます。

https://openweathermap.org/priceを参照して

@raisedadeadキャッシュがあることを意図した元のコードのようです。 これが事実であり、プライバシーを尊重するためにこれをどのように見せたいかについて詳細を滑らかにすることができれば、レート制限を回避できることを願っていますか？

考え直してみると、エラーメッセージの代わりに有効なデータを返すのがおそらく最善です。 代わりに、キャッシュを変更してランダムな気象条件を生成し、場所を「APIビジー、後で実際の結果を得るために再試行」に設定しましょう。

@raisedadead、これについてどう思いますか？

このプロジェクトを完了したばかりで、日本の気象データを受信する、または（ほとんどの場合）データを受信できないという問題を抱えている人として、データを受信する方がデータがないよりも便利だと言いたいです。 少なくとも日本のデータでは、正確な天気を示していても、コードが機能するかどうかを確認できました。

理論的には、ランダムなデータを送信できます。 しかし、データが正しくないという苦情は受けたくありません。これは間違いないでしょう。

とにかくそれが役立つなら、ランダムなデータを持ってみましょう。

@QuincyLarson上記のリクエストでご案内いただけますか？

偽のデータを送信する必要があると思いますが、それが偽であることを明確にしてください。 場所の名前を「APIBusy、Fake Data」とし、天気、座標などをランダムに応答します。 このようにして、人々は結果が正確でない理由を知っています。 それでも、すべてが開発者にとっては機能します。

考え？

偽のデータを送信すると、特定の場所の現在の気象データを提供するという目的全体が無効になると思います。 キャッシュを作成して実装する方法を理解するという@ joker314のアイデアが好きです。

最近のフォーラムディスカッションをプロジェクトページに固定して、コーダーがプロジェクトに問題があることを認識し、自分たちが制御できない問題を修正するために不必要な時間を費やさないようにすることを検討してください。

ところで、 https：//fcc-weather-api.glitch.me/で説明されているように、 iconの画像URLは返されないと思います。
Images links are included in the JSON under weather[0].iconと書かれていましたが、そうではありません。
デモソリューションがアイコンを描画するためにcssを記述していることに気づきました。

この潜在的な問題についてお知らせいただきありがとうございますが、リクエストと応答の例には目的のフィールドが含まれています。 このフィールドがない特定のリクエストをしましたか？

@ joker314Thx返信してください。

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どんなテストをしましたか？ 問題は、OpenWeatherAPIの呼び出しに使用される無料のFCCアカウントごとにレート制限があることです。 これらのレート制限に達すると、Glitchプロキシは日本の座標を返します。 現在問題と見なされていない唯一の理由は、このプロジェクトがカリキュラムでオプションになっているため、以前ほどヒットが少ないことです。 1分間にグリッチを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の開始時に修正に取り組み始め、その後QAプロセスに深く関わりました。 残りは歴史です。 実用的なソリューションを実行できるようにするには、NodeとExpressについての理解が深まったので、これをもう一度検討する必要があります。

エントリが1つしかない静的キャッシュ（日本の場所）があります。

レートリミッターを削除して修正するか（APIキーが1つしかないため、それが良いアイデアかどうかはわかりません）、リクエストの割り当てを超えた場合にレート制限エラーを返すことができます。

とにかく、グリッチに関するこのapiプロジェクトは@MiloATHが所有して

キャンピングカーボットアカウントを使用して、 https： //glitch.com/edit/#！/ fcc-weather-apiでMiloに参加リクエストを送信しました。

それらは良いアイデアのように聞こえます！ 3番目のオプションがあります。 データが実際にそこに保存されるようにキャッシュを修正するか、レートリミッターに達した場合にランダムデータを送信します。

このような状況ではAPIキーが取り消される可能性があり、いずれの場合もAPIから結果が得られない可能性があるため、レート制限を超えることはお勧めできません。

@ joker314私はすでにあなたの3番目の選択肢の方向に進んでいました。

グリッチプロジェクトへの招待状を渡しました。

エンドポイントは大幅に改善される可能性があります。 CIを使用して別のリポジトリを構築し、Heroku（無料バージョン）などのより成熟したものにデプロイする必要があると思います。 これにより、プロジェクトでより簡単に作業できるようになります。

herokuにはもうデプロイしていません。 今のところグリッチを使用します。 つまり、代替プロジェクトがある場合は、GlitchのfreeCodeCampのアカウントで展開し、カリキュラムの既存の課題を置き換えることができます。

@raisedadead @RandellDawson
こんにちは！ これに関する更新はありますか？
アーキテクチャとデータフロー（そして最終的には関連するファイル名）を含むいくつかの図を見るのは素晴らしいことです。

@ Hash2C既存のGlitchプロジェクト（以下に表示）をリミックスして、プロジェクトを表示および修正できます。

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

@RandellDawsonに感謝し

@ Hash2C時間をかけて正しく

@RandellDawsonに感謝し
現在の制約についてもう少し知る必要があります。
1分あたり60ヒットの制限があることを上で読みました。これは、OpenWeatherの価格設定の無料枠のようです。 この制限を増やす方法はありますか？ OWへの他のサブスクリプションを作成したいですか？ OWと一緒に使用できる他の無料の「信頼できる情報源」はありますか？

編集：また、どのような種類の遅延を提供することが許容されますか？ 5分？ 15分？ 1時間？ 3時間？

Edit2：この表に示されているように、OWの「WeatherAPIデータの更新」は「<2時間」のようです
https://openweathermap.org/price
同じ表から、可用性は95％にすぎないことがわかります

この制限を増やす方法はありますか？ OWへの他のサブスクリプションを作成したいですか？

また、IPアドレスに制限がある場合があるため（不明）、他のサブスクリプションを作成しても役に立ちません。

OWと一緒に使用できる他の無料の「信頼できる情報源」はありますか？

ちょっとわからない。

Edit2：この表に示されているように、OWの「WeatherAPIデータの更新」は「<2時間」のようです

私は現在、OpenWeatherの無料バージョンを使用して独自の気象プロジェクトを開発しており、リクエストが最後のリクエストから10分未満かどうかを確認してから、同じ緯度/経度で最後に返されたデータを表示することを検討しています。

チャレンジの手順を更新して、制限に達した場合に特別な応答を返信することを開発者に通知して、データが最新でない可能性があることをアプリユーザーに通知できるようにすることもできると思います。 それでも、現在と同じデータを返したいと思います（FCC APIを使用して古いプロジェクトを壊さないようにするため）。 応答にプロパティを追加するだけです。 どう思いますか？

ローカルでのテストが簡単になるように、このリポジトリを作成しました。
https://github.com/Hash2C/fccWeatherApiDraft

（今のところ）3つの主なユースケースはすでにカバーされていると思います

• 座標が無効/存在しない場合は、エラーを送信してください
  それ以外の場合は、座標を便利な形式に変換してから、キャッシュをヒットしようとします

• 要求された座標がキャッシュされている場合
  
  
  
  • タイムスタンプが許容可能なデルタ内にある場合：キャッシュされたデータを送信します（1）
  
  
  • else：モックデータをキャッシュデータとして設定します（後でOpenWeather api呼び出しが失敗した場合に備えて）
  
  

• else：モックデータを私たちが決定したものとして設定します（後でOpenWeather api呼び出しが失敗した場合に備えて）。

• OpenWeatherAPIを呼び出そうとします。

• 適切なデータを取得したら、それを送信し、キャッシュに保存します（2）
• それ以外の場合は、モックデータを送信します（3）

もちろん、このフローは非常にオープンです。

検証、非同期処理、エッジケース（テスト）など、やるべきことはまだたくさんありますが、徐々にそこに到達していきます。 server.jsファイルにたくさんコメントしました（怖がらないでください）。各問題について話し合うことができるように、その情報のほとんどを徐々にフィルタリングし、ここで助けを求めます。

ただのアイデア：「OpenWeatherAPI（または他のAPI）への利用可能なリクエストの数を最小限に抑えようとするデータサービスを最終的に作成できるでしょうか？」 このサービスは、たとえば、MongoDBデータベースにフィードします-それがキャッシュになります（Memcachedを使用できますが、多分多すぎるので、その余分な速度は必要ありません）

その他のアイデア：このサービスの過去の使用統計はありますか？ そうでない場合は、最終的には可能であるが非常に最適ではないソリューションを最適化するために、作成を開始することができます。

私が理解するために確かにいくつかの助けが必要になることの1つは、このセキュリティの問題githubが私に警告していることです

（どういうわけか私はあなたのメッセージを完全に逃しました！）

また、IPアドレスに制限がある場合があるため（不明）、他のサブスクリプションを作成しても役に立ちません。

いい視点ね。 テストする価値はありますか？

OWと一緒に使用できる他の無料の「信頼できる情報源」はありますか？

ちょっとわからない。

これを許可された場合、ソリューションが成功する可能性が大幅に高まる可能性があります。

私は現在、OpenWeatherの無料バージョンを使用して独自の気象プロジェクトを開発しており、リクエストが最後のリクエストから10分未満かどうかを確認してから、同じ緯度/経度で最後に返されたデータを表示することを検討しています。

はい、キャッシュされたデータを使用していますか？ 以前に許容可能な遅延について質問したので、2時間未満の質問をしました。 遅延が長ければ長いほど良いので、キャッシュにヒットする回数が増え、APIを頻繁に呼び出す必要がなくなります。 開始するためだけに、最大1時間前のデータを送信できると想定してコーディングを開始しました。

チャレンジの手順を更新して、制限に達した場合に特別な応答を返信することを開発者に通知して、データが最新でない可能性があることをアプリユーザーに通知できるようにすることもできると思います。 それでも、現在と同じデータを返したいと思います（FCC APIを使用して古いプロジェクトを壊さないようにするため）。 応答にプロパティを追加するだけです。 どう思いますか？

私は、開発者に関連情報を提供し、開発者に選択させるというこのアイデアに完全に同意します。これは、私が最も適切であると考えていたパスでもあります。

FCCプロジェクトでテストおよびリクエストを行うための標準ツールはありますか？
私が使用しているリクエストの場合（Axiosの代わりに試してみることにしたという理由だけで）
www.npmjs.com/package/request
テストに関してはあまり経験がありませんが、モカのことを考えていました。
ただし、どのツールがFCCとより適切に統合されるかを教えてください

私が理解するために確かにいくつかの助けが必要になることの1つは、このセキュリティの問題githubが私に警告していることです

最も簡単な解決策は、 npm audit fixを実行してから、更新されたpackage.jsonとpackage-lock.jsonコミットすることです。 新しいパッケージには、以前の脆弱なパッケージからの重大な変更はありません。 ただし、これはパッケージの作成者が誤って重大な変更を導入していないことを前提としているため、修正が適用された後、アプリを手動で確認する価値があります。

私はOpenWeatherAPIで遊んでいます（実際には最初からこれを行うべきでした）。
私たちはこれを知っていましたか？ https://openweathermap.org/faq#error401
関連部分

FOSS開発者向け：無料のオープンソースソフトウェアを歓迎し、喜んでお手伝いします。 無料のソフトウェアアプリケーションでOWMデータを使用する場合は、APIキーを登録し、アプリケーションと登録されているAPIキーを説明するチケットを提出してください。 OWMは、オープンソースアプリケーションで使用されている場合、キーのリクエストリフトアクセス制限を確認します。

こんにちはみんな、私は予想以上に制約されています。
暇なときは、OpenWeatherAPIを勉強しています。 残念ながら、それは十分に文書化されていません。
bboxオプションを使用して実行可能な戦略を思いついたと思いますが、まだテスト中です。
私が出会ったすべての情報、私が行っているテストを含むドキュメントを作成するというこのアイデアを思いつきました。

@ Hash2C時間をかけて正しく

@RandellDawson
あなたはあなたが言っていることを知っていました：heavy_check_mark：

@ Hash2Cソリューションはどのように進んでいますか？

このプロジェクトは認証に必要なプロジェクトではなくなったため、一般的にこのプロジェクトに取り組んでいるユーザーの数が大幅に減少したため、この問題を解決します。 これにより、APIのレート制限に達するインスタンスが少なくなりました。