Freecodecamp: FCC Weather API secara acak menampilkan cuaca Jepang

Sepertinya saya telah mengidentifikasi masalahnya! Ini hanya membaca dari cache , yang berisi data Jepang.

Cache hanya digunakan jika ada lebih dari enam puluh permintaan dalam antriannya (baris 50) Itu berarti _sometimes_ itu akan mengembalikan hasil yang benar; tetapi _sometimes_ itu akan mengembalikan hasil yang tidak terduga ini.

Bagaimana ini bisa diperbaiki? Kami memiliki tiga opsi ...

• Hapus cache
• Jadikan cache berfungsi, dan benar-benar gunakan data lintang dan bujur saat memutuskan apakah akan menggunakan cache.
  
  
  
  • Tolak permintaan sepenuhnya jika server merasa kelebihan beban ( disarankan untuk saat ini )
  
  

Karena ini memerlukan bantuan, saya ingin sekali melihat ini; namun, mengingat bagaimana ini mengganggu proyek, dan mengingat betapa saya perlu tidur, jika ada yang ingin memperbaikinya (cara termudah adalah dengan mengubah cache untuk menolak permintaan), silakan lakukan!

Oke, saya rasa saya sudah memperbaiki masalahnya . Saya tidak dapat mengujinya, karena saya tidak memiliki kunci API - dan, tentu saja, risiko DOS karena kami tidak pernah menggunakan cache.

Jadi, perbaikan bisa dilakukan. Haruskah kami, mungkin, menolak permintaan di mana jika tidak kami akan mengirimkan data Jepang? Ini terserah kalian semua. Saya memperbaikinya sementara dan saya akan mencoba membuatnya lebih baik besok.

Saya rasa saya tidak dapat melakukan pull request ke glitch.me API (kecuali, tentu saja, ada repositori di GitHub yang saya lewatkan); jadi seseorang dengan izin menulis perlu menggabungkan perubahan saya setelah mengujinya dengan kunci API yang berfungsi.

Benar, saya afk saat ini; tetapi saya menyadari bahwa pembatasan tarif diperlukan. Saya akan segera memperbaiki kode saya sehingga permintaan ditolak jika terlalu banyak panggilan API yang dilakukan.

Oke, sekarang saya pikir saya telah membuat solusi dalam jangka pendek. Saya tidak yakin apa yang ingin kita lakukan tentang pengumpulan data yang menakutkan - koordinatnya cenderung cukup tepat (haruskah kita membulatkannya untuk keperluan caching?). Kami pasti harus menandai hal-hal jika itu dari cache, untuk memperjelas bahwa itu tidak 100% akurat.

Bagaimanapun, untuk saat ini, setiap kali kode mencoba mengakses cache, itu malah akan mengirim pesan kesalahan.

 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"
+  }
  }

Hai @ joker314 Saya setuju dengan solusi Anda untuk menolak dengan kesalahan. Bisakah Anda membuat PR? Terima kasih banyak telah meluangkan waktu untuk menyelidiki ini.

@QuincyLarson Bisakah Anda memandu siapa yang memiliki akses ke https://fcc-weather-api.glitch.me/ ini? Saya dapat didelegasikan jika Anda adalah pemiliknya.

@raisedadead Saya ingin sekali, tetapi saya telah melihat-lihat dan saya tidak yakin apakah glitch.me benar-benar mendukung permintaan tarik - kecuali Anda juga memiliki salinannya di GitHub atau saya melewatkan sesuatu?

EDIT: Tentu saja, kode yang dikoreksi dapat ditemukan di remix saya.

@ joker314 ya Anda benar, kami akan memperbarui proyek dari remix Anda. Mohon abaikan komentar saya sebelumnya.

Saya menunggu Quincy pada konfirmasi akses ke proyek itu. Terima kasih banyak atas bantuan Anda dalam hal ini.

@raisedadead - Berapa lama perbaikan sementara ini akan diterapkan? Seperti apa solusi akhir untuk tampilan ini? Apakah ini hanya masalah batas kecepatan? Jika demikian, itu hanya akan menjadi lebih buruk karena lebih banyak berkemah membuat proyek cuaca. Bisakah rate-limit dinaikkan?

Jadi, berapa lama perbaikan sementara ini akan diterapkan?

Ini tidak akan bersifat sementara, dengan kesalahan akan diketahui bahwa masalah tersebut disebabkan oleh batas tarif.

Ini adalah pembungkus yang dibuat di atas OpenWeatherMaps API, yang menurut saya tidak mendukung https, dan karenanya bertentangan dengan codepen.

Jika demikian, itu hanya akan menjadi lebih buruk karena lebih banyak berkemah membuat proyek cuaca. Bisakah rate-limit dinaikkan?

Ya, Anda dapat memilih versi berbayar dengan mengintegrasikan API secara langsung sebagai ganti pembungkus kesalahan dalam tantangan.

Lihat https://openweathermap.org/price

@raisedadead Sepertinya kode asli yang dimaksudkan untuk dijadikan cache. Jika ini masalahnya, dan jika kami dapat memperhalus detail seperti apa yang kami inginkan untuk menghormati privasi, maka mudah-mudahan kami dapat mengatasi pembatasan tarif?

Setelah dipikir-pikir lagi, mungkin yang terbaik adalah mengembalikan data yang valid daripada pesan kesalahan. Mari kita ubah cache untuk menghasilkan kondisi cuaca acak, dan setel lokasi ke "API sibuk, coba lagi nanti untuk hasil nyata"?

Apa pendapat Anda tentang ini, @raisedadead?

Sebagai seseorang yang baru saja menyelesaikan proyek ini dan memiliki masalah menerima data cuaca Jepang atau (sebagian besar waktu) tidak ada data, saya ingin mengatakan bahwa menerima data lebih berguna daripada tidak ada data. Setidaknya dengan data Jepang saya dapat melihat apakah kode saya berfungsi terlepas dari itu menunjukkan cuaca yang akurat.

Secara teori, kami dapat mengirimkan data secara acak. Tetapi kami tidak ingin mendapatkan keluhan tentang data yang tidak benar .. yang saya yakin akan menjadi kasus.

Ngomong-ngomong jika itu membantu mari kita memiliki data acak.

@QuincyLarson dapatkah Anda memandu dengan permintaan di atas ?

Saya pikir kita harus mengirim data palsu, tetapi jelaskan bahwa itu palsu. Minta nama lokasi menjadi "API Sibuk, Data Palsu", dan cuaca, koordinat, dll. Diacak dalam respons. Dengan cara ini, orang tahu mengapa hasilnya tidak akurat; namun semuanya akan tetap berfungsi untuk pengembang.

Pikiran?

Jika Anda mengirim data palsu, saya yakin itu akan menggagalkan tujuan penyediaan data cuaca terkini untuk lokasi tertentu. Saya suka ide @ joker314 tentang mencari tahu bagaimana kita ingin membuat cache dan menerapkannya.

Apakah Anda akan mempertimbangkan untuk menyematkan diskusi forum terbaru di halaman proyek sehingga pembuat kode tahu ada masalah dengan proyek dan tidak menghabiskan waktu yang tidak perlu untuk mencoba memperbaiki sesuatu yang tidak mereka kendalikan?

BTW, saya pikir url gambar dari icon tidak dikembalikan seperti yang dijelaskan di https://fcc-weather-api.glitch.me/.
Dikatakan Images links are included in the JSON under weather[0].icon , yang sebenarnya bukan.
Saya perhatikan bahwa solusi demo menulis css untuk menggambar ikon.

Terima kasih telah memberi tahu kami tentang potensi masalah ini, tetapi contoh permintaan dan respons memang menyertakan bidang yang diinginkan. Permintaan khusus apa yang Anda buat yang tidak memiliki bidang ini?

@ joker314 Thx untuk membalas.

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}

Saya tidak memperhatikan bahwa contoh berfungsi dengan baik, jadi saya kira ini mungkin karena lokasi atau cuaca khusus?

@ Em-Ant Sepertinya ini adalah masalah dengan aplikasi yang berjalan di Glitch. Bisakah Anda melihat tembolok dan melihat apakah ini sesuatu yang dapat kami bersihkan?

Saya melakukan beberapa tes cepat, saya yakin ini sudah diperbaiki. Jika ada yang masih mengalami masalah, silakan buka kembali masalah ini.

@ moT01 Tes seperti apa yang Anda lakukan? Masalahnya adalah ada batasan tarif per akun FCC gratis yang digunakan untuk melakukan panggilan ke OpenWeather API. Setelah batas kecepatan tersebut tercapai, proxy Glitch mengembalikan koordinat Jepang. Satu-satunya alasan mengapa hal ini tidak dilihat sebagai masalah saat ini, adalah bahwa proyek ini sekarang bersifat opsional dalam kurikulum, jadi tidak ada banyak hit seperti dulu. Segera setelah Anda menekan Glitch 60 kali dalam satu menit, JSON berikut dikembalikan:

{
  "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
}

Dapatkah Anda membuka kembali masalah ini, karena masih ada dalam daftar tugas yang harus saya perbaiki?

Ahh, ya - Saya baru saja melakukan beberapa panggilan cepat ke api dan bisa mendapatkan cuaca yang benar. Saya kira saya mungkin harus bertanya lebih banyak sebelum menutup masalah.

Saya mulai mengerjakan perbaikan tepat di awal Hacktoberfest dan kemudian sangat terlibat dengan proses QA. Sisanya adalah sejarah. Saya perlu meninjau kembali ini lagi, karena sekarang saya memiliki pemahaman yang jauh lebih baik tentang Node dan Express untuk dapat menjalankan solusi yang berfungsi.

Ada cache statis yang hanya memiliki satu entri (lokasinya di Jepang).

Kami dapat memperbaikinya dengan menghapus pembatas laju (saya tidak tahu apakah itu ide yang bagus, karena kami hanya memiliki satu kunci api di sana), atau mengembalikan kesalahan batas kecepatan jika kami melebihi kuota permintaan.

Bagaimanapun, proyek api pada kesalahan ini dimiliki oleh @MiloATH , dan kami tidak dapat mengeditnya tanpa 'mencabangnya', yaitu membuat aplikasi baru dengan url baru.

Saya telah mengirimkan permintaan bergabung di https://glitch.com/edit/#!/fcc -weather-api menggunakan akun camperbot ke Milo.

Kedengarannya seperti ide bagus! Ada pilihan ketiga; untuk memperbaiki cache sehingga data benar-benar disimpan di sana - atau untuk mengirim data acak jika pembatas laju dipukul.

Saya khawatir melebihi batas kecepatan bukanlah ide yang baik karena kunci API dapat dicabut dalam keadaan seperti itu, dan kami mungkin tidak mendapatkan hasil dari API dalam hal apa pun.

@ joker314 Saya sudah bergerak ke arah opsi ketiga Anda.

Saya telah menyampaikan undangan ke proyek kesalahan.

Titik akhir bisa jauh lebih baik. Saya pikir kita harus membangun repo terpisah dengan CI dan menerapkannya ke sesuatu yang lebih matang seperti Heroku (versi gratis). Ini akan memungkinkan kami untuk lebih mudah mengerjakan proyek.

Kami tidak menerapkan ke heroku lagi. Kami akan menggunakan Glitch untuk saat ini. Artinya jika ada proyek alternatif kami dengan senang hati menerapkannya di bawah akun freeCodeCamp di Glitch dan mengganti tantangan yang ada di Kurikulum

@rumahsakitotak
Hai! Ada pembaruan tentang ini?
Akan luar biasa untuk melihat beberapa diagram dengan arsitektur dan aliran data (dan akhirnya nama file yang terkait)

@ Hash2C Anda dapat me-remix proyek Glitch yang ada (ditampilkan di bawah) untuk melihat dan memperbaiki proyek.

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

Terima kasih @RandellDawson , saya sudah mengerjakannya, semoga saya bisa menyelesaikan draf pertama hingga Kamis

@ Hash2C Luangkan waktu Anda untuk melakukannya dengan benar. Bug ini sudah ada cukup lama.

Terima kasih @RandellDawson , saya akan melakukan yang terbaik.
Saya perlu tahu lebih banyak tentang kendala saat ini.
Saya membaca di atas bahwa kami memiliki batas 60 klik per menit, yang tampaknya merupakan tingkat gratis dalam harga OpenWeather. Apakah ada cara untuk meningkatkan batas ini? Suka membuat langganan lain ke OW? Apakah ada "sumber kebenaran" gratis lainnya yang dapat kita gunakan bersama dengan OW?

Sunting: Juga, penundaan seperti apa yang dapat diterima untuk disampaikan? 5 menit? 15 menit? 1j? 3j?

Edit2: Sepertinya OW "Pembaruan data API cuaca" adalah "<2 jam" seperti yang terlihat pada tabel ini
https://openweathermap.org/price
Tabel yang sama memberi tahu kita bahwa ketersediaan hanya 95%

Apakah ada cara untuk meningkatkan batas ini? Suka membuat langganan lain ke OW?

Mereka mungkin juga memiliki batasan pada alamat ip (tidak yakin), jadi membuat langganan lain tidak akan membantu.

Apakah ada "sumber kebenaran" gratis lainnya yang dapat kita gunakan bersama dengan OW?

Tidak yakin.

Edit2: Sepertinya OW "Pembaruan data API cuaca" adalah "<2 jam" seperti yang terlihat pada tabel ini

Saat ini saya sedang mengembangkan proyek cuaca saya sendiri menggunakan versi gratis OpenWeather dan saya telah mempertimbangkan untuk memeriksa apakah permintaan tersebut kurang dari 10 menit dari permintaan terakhir, kemudian menunjukkan data yang dikembalikan terakhir untuk lintang / bujur yang sama.

Saya rasa kami juga dapat memperbarui instruksi tantangan untuk memberi tahu pengembang bahwa kami akan mengirim kembali tanggapan khusus jika batas tercapai, sehingga mereka dapat memberi tahu pengguna aplikasi bahwa data mungkin tidak mutakhir. Kami masih ingin mengembalikan data yang sama seperti saat ini (agar tidak merusak proyek lama menggunakan FCC API). Kami hanya akan menambahkan properti tambahan ke respons. Bagaimana menurut anda?

Saya membuat repo ini sehingga lebih mudah untuk menguji secara lokal.
https://github.com/Hash2C/fccWeatherApiDraft

Saya yakin 3 kasus penggunaan utama (untuk saat ini) sudah tercakup

• Jika koordinat tidak valid / tidak ada, kirim kesalahan
  lain, konversikan coord ke format yang nyaman dan kemudian kami mencoba untuk menekan cache

• Jika koordinat yang diminta di-cache
  
  
  
  • Jika stempel waktu berada dalam delta yang dapat diterima: kirim data dalam cache (1)
  
  
  • else: setel data tiruan sebagai data cache (jika nanti panggilan api OpenWeather gagal)
  
  

• else: setel data tiruan sebagai sesuatu yang kita putuskan (jika nanti panggilan api OpenWeather gagal).

• Kami mencoba memanggil api OpenWeather.

• Jika kami mendapatkan data yang benar, kirimkan, simpan di cache (2)
• Lain, kirim data yang mengejek (3)

Aliran ini tentu saja sangat terbuka untuk diskusi!

Masih banyak pekerjaan yang harus dilakukan, validasi, async, kasus edge (tes), dll. Tetapi kami akan secara bertahap sampai di sana. Saya banyak mengomentari file server.js (jangan menakutkan), saya akan secara bertahap menyaring sebagian besar informasi itu dan meminta bantuan Anda di sini sehingga kita dapat mendiskusikan setiap masalah.

Hanya sebuah ide: bisakah kita pada akhirnya memiliki layanan data, yang mencoba meminimalkan jumlah "permintaan yang tersedia ke OpenWeather API (atau lainnya) yang tidak dibuat"? Layanan ini akan memberi makan, katakanlah, database MongoDB - itu akan menjadi cache kami (kami dapat menggunakan Memcached tetapi itu mungkin terlalu banyak, kami tidak memerlukan kecepatan ekstra itu)

Ide lain: Apakah ada statistik penggunaan sebelumnya dari layanan ini? Jika tidak, mungkin kita bisa mulai membuatnya, mungkin itu bisa berguna, untuk mencoba mengoptimalkan solusi yang pada akhirnya mungkin tetapi sangat suboptimal

Satu hal yang pasti perlu saya pahami adalah Masalah Keamanan yang memperingatkan saya tentang Masalah Keamanan ini

(untuk beberapa alasan saya benar-benar melewatkan pesan Anda!)

Mereka mungkin juga memiliki batasan pada alamat ip (tidak yakin), jadi membuat langganan lain tidak akan membantu.

Poin yang bagus. Apakah ini layak untuk diuji?

Apakah ada "sumber kebenaran" gratis lainnya yang dapat kita gunakan bersama dengan OW?

Tidak yakin.

Jika kita diizinkan untuk melakukan ini, ini mungkin sangat meningkatkan kemungkinan mencapai solusi yang berhasil.

Saat ini saya sedang mengembangkan proyek cuaca saya sendiri menggunakan versi gratis OpenWeather dan saya telah mempertimbangkan untuk memeriksa apakah permintaan tersebut kurang dari 10 menit dari permintaan terakhir, kemudian menunjukkan data yang dikembalikan terakhir untuk lintang / bujur yang sama.

Ya, menggunakan data cache kan? Saya membawa pertanyaan <2 jam itu karena saya bertanya sebelumnya tentang penundaan yang dapat diterima. Semakin lama penundaannya, semakin baik, jadi kami lebih sering menekan cache dan tidak perlu terlalu sering memanggil api. Memulai pengkodean dengan asumsi kita dapat mengirim data paling lama 1 jam, hanya untuk memulainya.

Saya rasa kami juga dapat memperbarui instruksi tantangan untuk memberi tahu pengembang bahwa kami akan mengirim kembali tanggapan khusus jika batas tercapai, sehingga mereka dapat memberi tahu pengguna aplikasi bahwa data mungkin tidak mutakhir. Kami masih ingin mengembalikan data yang sama seperti saat ini (agar tidak merusak proyek lama menggunakan FCC API). Kami hanya akan menambahkan properti tambahan ke respons. Bagaimana menurut anda?

Saya sangat setuju dengan gagasan memberikan info yang relevan kepada pengembang dan membiarkan mereka memilih, ini adalah jalan yang saya anggap paling memadai juga.

Apakah ada alat standar untuk Pengujian dan untuk membuat Permintaan dalam proyek FCC?
Untuk Permintaan yang saya gunakan (hanya karena saya memutuskan untuk mencobanya, bukan Axios)
www.npmjs.com/package/request
Untuk pengujian saya tidak punya banyak pengalaman tetapi saya berpikir tentang Mocha.
Tapi tolong beri tahu saya alat mana yang lebih terintegrasi dengan FCC

Satu hal yang pasti perlu saya pahami adalah Masalah Keamanan yang memperingatkan saya tentang Masalah Keamanan ini

Solusi paling sederhana adalah menjalankan npm audit fix dan kemudian melakukan pembaruan package.json dan package-lock.json . Paket baru seharusnya tidak memiliki perubahan yang merusak dari yang sebelumnya, yang rentan. Namun, itu mengasumsikan pembuat paket tidak secara tidak sengaja memperkenalkan perubahan yang dapat menyebabkan gangguan, jadi sebaiknya periksa aplikasi Anda secara manual setelah perbaikan diterapkan.

Saya telah bermain dengan api OpenWeather (sebenarnya saya seharusnya melakukan ini dari awal).
Apakah kami mengetahui hal ini? https://openweathermap.org/faq#error401
Bagian yang relevan

Untuk pengembang FOSS: kami menerima perangkat lunak gratis dan sumber terbuka serta bersedia membantu Anda. Jika Anda ingin menggunakan data OWM dalam aplikasi perangkat lunak gratis Anda, harap daftarkan kunci API dan ajukan tiket yang menjelaskan aplikasi Anda dan kunci API yang terdaftar. OWM akan meninjau permintaan Anda mengangkat batas akses untuk kunci Anda jika digunakan dalam aplikasi sumber terbuka.

Halo teman-teman, saya lebih terkekang dari yang diharapkan.
Di waktu luang saya, saya telah mempelajari api OpenWeather. Sayangnya tidak terdokumentasi dengan baik.
Saya pikir saya datang dengan strategi yang layak, menggunakan opsi bbox, tetapi saya masih menguji.
Saya mendapatkan ide untuk membuat dokumen dengan semua info yang saya temukan, tes yang saya lakukan.

@ Hash2C Luangkan waktu Anda untuk melakukannya dengan benar. Bug ini sudah ada cukup lama.

@Rell
Anda tahu apa yang Anda katakan: heavy_check_mark:

@ Hash2C Bagaimana solusi Anda datang?

Menutup masalah ini karena jumlah pengguna yang mengerjakan proyek ini secara umum telah turun secara signifikan karena tidak lagi menjadi proyek wajib untuk sertifikasi. Hal ini menyebabkan lebih sedikit contoh di mana batas kecepatan untuk API tercapai.