Freecodecamp: FCC मौसम एपीआई बेतरतीब ढंग से जापान का मौसम लौट रहा है

मुझे लगता है कि मैंने इस मुद्दे की पहचान कर ली है! यह केवल कैश से पढ़ रहा है , जिसमें जापानी डेटा है।

कैश का उपयोग केवल तभी किया जाता है जब उसकी कतार (पंक्ति 50) में साठ से अधिक अनुरोध हों, इसका मतलब है कि _sometimes_ यह सही परिणाम लौटाएगा; लेकिन _sometimes_ यह, अप्रत्याशित परिणाम देगा।

इसे कैसे सुधारा जा सकता है? हमारे पास तीन विकल्प हैं ...

• कैश निकालें
• कैश को क्रियाशील बनाएं, और वास्तव में कैश का उपयोग करने का निर्णय लेते समय अक्षांश और देशांतर डेटा का उपयोग करें।
  
  
  
  • यदि सर्वर ओवरलोडेड लगता है तो अनुरोध को पूरी तरह से अस्वीकार कर दें ( अब के लिए अनुशंसित )
  
  

चूँकि यह एक हेल्प-वॉन्टेड है, मुझे इस पर एक नज़र डालना अच्छा लगेगा; हालाँकि, यह देखते हुए कि यह परियोजनाओं को कैसे बाधित कर रहा है, और यह देखते हुए कि मुझे नींद की ज़रूरत कैसे है, अगर कोई इसे ठीक करना चाहता है (सबसे आसान तरीका है कि आप अनुरोधों को अस्वीकार करने के लिए कैश को बदलना चाहते हैं), तो कृपया ऐसा करें!

ठीक है, मुझे लगता है कि मैंने इस मुद्दे को ठीक कर दिया है । मैं इसका परीक्षण नहीं कर सका, हालांकि, मेरे पास एपीआई कुंजी का अभाव था - और निश्चित रूप से, डॉस के जोखिम को देखते हुए कि हम कभी भी कैशिंग का सहारा नहीं लेते हैं।

ताकि, सुधार किया जा सके। क्या हमें, शायद अनुरोधों को अस्वीकार करना चाहिए, अन्यथा हम जापानी डेटा कहां भेजेंगे? यह y'all तक है। मेरा यह अस्थायी है और मैं इसे बेहतर कल बनाने पर काम करने की कोशिश करूंगा।

मुझे नहीं लगता कि मैं glitch.me API के लिए एक पुल अनुरोध कर सकता हूं (जब तक कि निश्चित रूप से, GitHub पर एक रिपॉजिटरी नहीं है जो मुझे याद आया); इसलिए लिखने की अनुमति वाले किसी व्यक्ति को कार्यशील एपीआई कुंजी के साथ परीक्षण करने के बाद मेरे परिवर्तनों को मर्ज करने की आवश्यकता होगी।

ठीक है, मैं इस समय afk हूं; लेकिन मुझे एहसास हुआ कि दर सीमित करने की आवश्यकता है। मैं जल्द ही अपना कोड ठीक कर दूंगा ताकि बहुत से एपीआई कॉल किए जाने पर अनुरोधों से इनकार कर दिया जाए।

ठीक है, मुझे लगता है कि मैंने अल्पकालिक में एक समाधान बनाया है। मुझे यकीन नहीं है कि हम डरावने डेटा संग्रह के बारे में क्या करना चाहते हैं, हालांकि - निर्देशांक काफी सटीक हैं (क्या हमें purpurses कैशिंग के लिए उन्हें गोल करना चाहिए?)। हमें निश्चित रूप से चीजों को चिह्नित करना चाहिए यदि वे कैश से हैं, तो यह स्पष्ट करने के लिए कि यह 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 मुझे पसंद

संपादित करें: निश्चित रूप से, सही कोड मेरे रीमिक्स पर पाया जा सकता है।

@ joker314 हाँ, आप सही हैं, हम आपके रीमिक्स से प्रोजेक्ट को अपडेट करेंगे। कृपया मेरी पिछली टिप्पणी को नजरअंदाज करें।

मैं उस परियोजना के उपयोग की पुष्टि पर क्विंसी पर इंतजार कर रहा हूं। इसके साथ आपकी मदद के लिए बहुत बहुत धन्यवाद।

@raisedadead - तो यह अस्थायी निर्धारण कब तक होगा? इस तरह के लिए अंतिम समाधान क्या होगा? क्या यह सिर्फ दर-सीमा का मुद्दा है? यदि ऐसा है, तो यह खराब होने वाला है क्योंकि अधिक कैंपर मौसम परियोजनाएं बनाते हैं। क्या रेट-लिमिट बढ़ाई जा सकती है?

तो यह अस्थायी सुधार कब तक लागू रहेगा?

यह अस्थायी नहीं होगा, त्रुटि के साथ यह पता चल जाएगा कि मुद्दा दर सीमाओं के कारण है।

यह OpenWeatherMaps API के शीर्ष पर बनाया गया एक आवरण था, जो कि मेरे विचार से https का समर्थन नहीं कर रहा था, और इसलिए कोडपेन के साथ विरोध किया।

यदि ऐसा है, तो यह खराब होने वाला है क्योंकि अधिक कैंपर मौसम परियोजनाएं बनाते हैं। क्या रेट-लिमिट बढ़ाई जा सकती है?

हां, आप चुनौती में गड़बड़ आवरण के बजाय सीधे एपीआई को एकीकृत करके एक भुगतान किए गए संस्करण का विकल्प चुन सकते हैं।

Https://openweathermap.org/price देखें

@raisedadead ऐसा लगता है कि मूल कोड का उद्देश्य वहां कैश होना है। यदि यह मामला है, और यदि हम विवरणों को आसानी से समझ सकते हैं कि हम गोपनीयता का सम्मान करना चाहते हैं, तो उम्मीद है कि हम दर सीमित कर सकते हैं?

दूसरे विचार पर, शायद एक त्रुटि संदेश के बजाय वैध डेटा वापस देना सबसे अच्छा है। आइए इसके बजाय यादृच्छिक मौसम की स्थिति उत्पन्न करने के लिए कैश को बदलें, और "एपीआई व्यस्त, वास्तविक परिणामों के लिए बाद में फिर से प्रयास करें" स्थान निर्धारित करें?

इस पर आपके क्या विचार हैं, @raisedadead?

जैसा कि कोई व्यक्ति जो इस परियोजना को पूरा कर रहा है और उसके पास जापानी मौसम डेटा प्राप्त करने का मुद्दा था या (ज्यादातर समय) कोई डेटा नहीं, मैं यह कहना चाहूंगा कि कोई भी डेटा प्राप्त करना डेटा की तुलना में अधिक उपयोगी है। कम से कम जापानी डेटा के साथ मैं देख सकता था कि क्या मेरे कोड ने सटीक मौसम दिखाने के बावजूद काम किया।

अच्छी तरह से सिद्धांत रूप में, हम यादृच्छिक डेटा भेज सकते हैं। लेकिन हम डेटा के गलत होने की शिकायत नहीं करना चाहते हैं .. जो मुझे पूरा यकीन है कि एक मामला होगा।

वैसे भी अगर यह मदद करता है यादृच्छिक डेटा है।

@QuincyLarson क्या आप उपरोक्त अनुरोध के साथ मार्गदर्शन कर सकते हैं?

मुझे लगता है कि हमें नकली डेटा भेजना चाहिए, लेकिन यह स्पष्ट करें कि यह नकली है। क्या स्थान का नाम "एपीआई व्यस्त, नकली डेटा" हो सकता है, और प्रतिक्रिया में मौसम, निर्देशांक, आदि को यादृच्छिक किया जाएगा। इस तरह, लोग जानते हैं कि परिणाम सटीक क्यों नहीं हैं; और फिर भी सब कुछ अभी भी डेवलपर्स के लिए काम करेगा।

विचार?

यदि आप नकली डेटा भेजते हैं, तो मेरा मानना ​​है कि यह एक विशिष्ट स्थान के लिए वर्तमान मौसम डेटा प्रदान करने के पूरे उद्देश्य को हरा देगा। मुझे @ joker314 का

कृपया प्रोजेक्ट पृष्ठ पर हाल के फोरम चर्चाओं को पिन करने पर विचार करेंगे ताकि कोडर्स को पता चले कि परियोजना के साथ कुछ समस्याएँ हैं और अनावश्यक समय व्यतीत करने की कोशिश नहीं कर रहे हैं ताकि वे नियंत्रण न कर सकें?

BTW, मुझे लगता है कि icon का url https://fcc-weather-api.glitch.me/ में वर्णित नहीं है
इसने कहा Images links are included in the JSON under weather[0].icon , जो नहीं है।
मैंने देखा कि डेमो समाधान आइकन को खींचने के लिए सीएसएस लिखा था।

धन्यवाद fot हमें इस संभावित मुद्दे के बारे में बताने देता है, लेकिन amd प्रतिक्रिया के उदाहरण अनुरोध में वांछित क्षेत्र शामिल है। आपने इस क्षेत्र में क्या विशेष अनुरोध नहीं किया?

@ जोकर 314 जवाब देने के लिए 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 आपने किस तरह के परीक्षण किए? मुद्दा यह है कि OpenWeather API पर कॉल करने के लिए उपयोग किए जाने वाले मुक्त FCC खाते की दर सीमा है। एक बार उन दरों की सीमा तक पहुँचने के बाद ग्लिच प्रॉक्सी जापान के निर्देशांक लौटा देता है। एकमात्र कारण इसे अभी एक मुद्दे के रूप में नहीं देखा जा रहा है, यह है कि यह परियोजना अब पाठ्यक्रम में वैकल्पिक है, इसलिए इसमें उतने हिट नहीं हैं जितने पहले हुआ करते थे। जैसे ही आप एक मिनट में 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
}

क्या आप इस मुद्दे को फिर से खोल सकते हैं, क्योंकि यह अभी भी ठीक करने के लिए मेरी परियोजनाओं की सूची पर है?

आह, हाँ - मैंने सिर्फ आपी को एक दो फोन किए और सही मौसम पाने में सक्षम था। मुझे लगता है कि मुद्दों को बंद करने से पहले मुझे शायद थोड़ा और पूछताछ करनी चाहिए।

मैंने Hacktoberfest की शुरुआत में एक सही पर काम करना शुरू कर दिया और फिर QA प्रक्रिया के साथ भारी जुड़ गया। बाकी इतिहास है। मुझे इस पर फिर से विचार करने की आवश्यकता है, क्योंकि अब मेरे पास नोड और एक्सप्रेस की बेहतर समझ है, जिससे काम करने का समाधान मिल सकेगा।

एक स्थिर कैश है जिसमें केवल एक प्रविष्टि (जापान में स्थान) है।

हम इसे रेट लिमिटर को हटाकर ठीक कर सकते हैं (मुझे नहीं पता कि यह एक अच्छा विचार है, क्योंकि हमारे पास केवल एक एपी कुंजी है), या अनुरोध कोटा से अधिक होने की स्थिति में एक दर सीमा त्रुटि वापस करें।

वैसे भी ग्लिच पर यह एपीआई प्रोजेक्ट फोर्किंग ' के बिना संपादित नहीं कर सकते हैं, अर्थात एक नए यूआरएल के साथ एक नया ऐप बना सकते हैं।

मैंने https://oitchitch.com/edit/#//fcc -weather-api पर कैंपरबोट खाते का उपयोग करके मिलो को एक अनुरोध भेजा है।

वे अच्छे विचारों की तरह लग रहे हैं! एक तीसरा विकल्प है; कैश को ठीक करने के लिए ताकि डेटा वास्तव में वहां संग्रहीत हो - या यादृच्छिक डेटा भेजने के लिए यदि दर सीमक मारा जाता है।

मुझे डर है कि दर सीमा पार करना एक अच्छा विचार नहीं है क्योंकि ऐसी परिस्थिति में एपीआई कुंजी को रद्द किया जा सकता है, और हमें किसी भी स्थिति में एपीआई से परिणाम नहीं मिल सकता है।

@ जोकर 314 मैं आपके तीसरे विकल्प की दिशा में आगे बढ़ रहा था।

मैं गड़बड़ परियोजना के लिए एक निमंत्रण पर पारित किया है।

समापन बिंदु काफी बेहतर हो सकता है। मुझे लगता है कि हमें सीआई के साथ एक अलग रेपो का निर्माण करना चाहिए और हरोकू (मुफ्त संस्करण) की तरह कुछ और परिपक्व करने के लिए तैनात करना चाहिए। यह हमें प्रोजेक्ट पर अधिक आसानी से काम करने की अनुमति देगा।

हम किसी भी अधिक के लिए तैनात नहीं कर रहे हैं। हम अभी के लिए ग्लिच का उपयोग करेंगे। मतलब अगर कोई वैकल्पिक परियोजना है तो हम उसे फ्रीचोडकैंप के खाते में ग्लिच पर तैनात करने में खुश हैं और पाठ्यचर्या में मौजूदा चुनौती को प्रतिस्थापित करते हैं

@raisedadead @RandellDawson
नमस्ते! इस पर कोई अपडेट?
यह वास्तुकला और डेटा प्रवाह के साथ कुछ आरेखों को देखने के लिए भयानक होगा (और अंततः संबद्ध फ़ाइलनाम)

@ Hash2C आप प्रोजेक्ट को देखने और ठीक करने के लिए मौजूदा ग्लिच प्रोजेक्ट (नीचे दिखाया गया) को रीमिक्स कर सकते हैं।

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

धन्यवाद @RandellDawson , मैं इस पर काम कर रहा हूं, मुझे उम्मीद है कि मैं गुरुवार तक एक पहला मसौदा पूरा कर सकता हूं

@ Hash2C इसे ठीक करने के लिए अपना समय लें। इस बग को यहां काफी समय हो गया है।

धन्यवाद @RandellDawson , मैं अपना सर्वश्रेष्ठ करूँगा।
मुझे वर्तमान बाधाओं के बारे में थोड़ा और जानने की जरूरत है।
मैंने ऊपर पढ़ा है कि हमारे पास प्रति मिनट 60 हिट्स की सीमा है, जो कि ओपन वेयर प्राइसिंग में फ्री टियर लगता है। क्या इस सीमा को बढ़ाने का कोई तरीका है? OW को अन्य सदस्यताएँ बनाने की तरह? क्या अन्य स्वतंत्र "सत्य के स्रोत" हैं जिनका उपयोग हम OW के साथ कर सकते हैं?

संपादित करें: इसके अलावा, किस तरह की देरी से डिलीवरी करना स्वीकार्य होगा? 5 मिनट? 15 मिनट? 1 घंटे? 3 ज?

Edit2: ऐसा लगता है कि OW "वेदर एपीआई डेटा अपडेट" "<2 घंटे" है जैसा कि इस तालिका में देखा गया है
https://openweathermap.org/price
एक ही तालिका हमें बताती है कि उपलब्धता केवल 95% है

क्या इस सीमा को बढ़ाने का कोई तरीका है? OW को अन्य सदस्यताएँ बनाने की तरह?

उनके पास आईपी पते की सीमाएं भी हो सकती हैं (निश्चित नहीं), इसलिए अन्य सदस्यताएँ बनाने से मदद नहीं मिलेगी।

क्या अन्य स्वतंत्र "सत्य के स्रोत" हैं जिनका उपयोग हम OW के साथ कर सकते हैं?

यकीन नहीं।

Edit2: ऐसा लगता है कि OW "वेदर एपीआई डेटा अपडेट" "<2 घंटे" है जैसा कि इस तालिका में देखा गया है

मैं वर्तमान में OpenWeather के मुक्त संस्करण का उपयोग करके अपनी खुद की मौसम परियोजना विकसित कर रहा हूं और मैंने अभी-अभी जाँच की है कि यदि अनुरोध अंतिम अनुरोध से 10 मिनट से कम है, तो उसी lat / lon के लिए अंतिम लौटा डेटा दिखाएं।

मुझे लगता है कि हम डेवलपर को यह बताने के लिए चुनौती के निर्देशों को भी अपडेट कर सकते हैं कि अगर हम एक सीमा तक पहुँच जाते हैं तो हम एक विशेष प्रतिक्रिया वापस भेज देंगे, इसलिए वे एक ऐप उपयोगकर्ता को यह बता सकते हैं कि डेटा अप-टू-डेट नहीं हो सकता है। हम अभी भी वही डेटा वापस करना चाहते हैं जो हम वर्तमान में कर रहे हैं (इसलिए एफसीसी एपीआई का उपयोग करके किसी भी पुरानी परियोजनाओं को तोड़ने के लिए नहीं)। हम केवल प्रतिक्रिया में एक अतिरिक्त संपत्ति जोड़ रहे होंगे। तुम क्या सोचते हो?

मैंने इस रेपो को बनाया है ताकि स्थानीय स्तर पर परीक्षण करना आसान हो जाए।
https://github.com/Hash2C/fccWeatherApiDraft

मेरा मानना ​​है कि 3 मुख्य उपयोग के मामले (अभी के लिए) पहले से ही कवर किए गए हैं

• यदि निर्देशांक अमान्य / अक्षम हैं, तो एक त्रुटि भेजें
  और, कोर्ड्स को एक सुविधाजनक प्रारूप में बदलें और फिर हम कैश को हिट करने का प्रयास करें

• यदि अनुरोध किए गए निर्देशांक कैश किए गए हैं
  
  
  
  • अगर टाइमस्टैम्प स्वीकार्य डेल्टा के भीतर है: कैश्ड डेटा (1) भेजें
  
  
  • और: सेट किए गए डेटा के रूप में नकली डेटा सेट करें (यदि बाद में OpenWeather एपीआई कॉल विफल हो जाए)
  
  

• और: कुछ डेटा जो हम तय करते हैं (बाद में OpenWeather एपीआई कॉल विफल हो जाता है) के रूप में नकली डेटा सेट करें।

• हम OpenWeather एपीआई को कॉल करने का प्रयास करते हैं।

• अगर हमें सही डेटा मिलता है, तो उसे भेजें, कैश में स्टोर करें (2)
• अन्य, नकली डेटा भेजें (3)

यह प्रवाह बेशक चर्चा के लिए खुला है!

अभी भी बहुत काम करना है, मान्यताएँ, एसिंक्स सामान, किनारे मामले (परीक्षण), आदि, लेकिन हम धीरे-धीरे वहां पहुंचेंगे। मैंने server.js फ़ाइल को बहुत टिप्पणी की (डरावना नहीं हुआ), मैं धीरे-धीरे उस जानकारी को फ़िल्टर करूंगा और आपसे सहायता मांगूंगा ताकि हम प्रत्येक मुद्दे पर चर्चा कर सकें।

बस एक विचार: क्या हमारे पास अंततः एक डेटा सेवा हो सकती है, जो "ओपनव्हीयर एपीआई (या अन्य) जो उपलब्ध नहीं होती है" की संख्या को कम करने की कोशिश करती है? यह सेवा, एक मोंगोडीबी डेटाबेस कहेगी - कि हमारा कैश होगा (हम मेम्केड का उपयोग कर सकते हैं, लेकिन यह शायद बहुत अधिक है, हमें उस अतिरिक्त गति की आवश्यकता नहीं है)

अन्य विचारधारा: क्या इस सेवा के पिछले उपयोग के आँकड़े हैं? यदि नहीं, तो शायद हम एक को बनाना शुरू कर सकते हैं, हो सकता है कि यह उपयोगी हो, अंततः संभव हो लेकिन बहुत उप-स्तरीय समाधान का अनुकूलन करने का प्रयास करें।

एक बात मुझे निश्चित रूप से समझने के लिए कुछ मदद की ज़रूरत है, यह सुरक्षा समस्या है github मुझे इसके बारे में चेतावनी दे रही है

(किसी कारण से मैं आपके संदेश से पूरी तरह चूक गया!)

उनके पास आईपी पते की सीमाएं भी हो सकती हैं (निश्चित नहीं), इसलिए अन्य सदस्यताएँ बनाने से मदद नहीं मिलेगी।

अच्छी बात। क्या यह परीक्षण के लायक है?

क्या अन्य स्वतंत्र "सत्य के स्रोत" हैं जिनका उपयोग हम OW के साथ कर सकते हैं?

यकीन नहीं।

यदि हमें ऐसा करने की अनुमति दी जाती है, तो यह एक सफल समाधान प्राप्त करने की संभावना को बहुत बढ़ा सकता है।

मैं वर्तमान में OpenWeather के मुक्त संस्करण का उपयोग करके अपनी खुद की मौसम परियोजना विकसित कर रहा हूं और मैंने अभी-अभी जाँच की है कि यदि अनुरोध अंतिम अनुरोध से 10 मिनट से कम है, तो उसी lat / lon के लिए अंतिम लौटा डेटा दिखाएं।

हाँ, कैश्ड डेटा का उपयोग करना सही है? मैं उस <2h प्रश्न को लाया क्योंकि मैंने पहले स्वीकार्य देरी के बारे में पूछा था। जितनी देर होगी, बेहतर होगा, इसलिए हमने कैश को अधिक मारा और हमें एपि को इतनी बार कॉल करने की आवश्यकता नहीं है। आरंभिक कोडिंग यह मानते हुए कि हम अधिकतम 1 घंटे में डेटा भेजने का प्रबंधन कर सकते हैं, बस इसे शुरू करने के लिए।

मुझे लगता है कि हम डेवलपर को यह बताने के लिए चुनौती के निर्देशों को भी अपडेट कर सकते हैं कि अगर हम एक सीमा तक पहुँच जाते हैं तो हम एक विशेष प्रतिक्रिया वापस भेज देंगे, इसलिए वे एक ऐप उपयोगकर्ता को यह बता सकते हैं कि डेटा अप-टू-डेट नहीं हो सकता है। हम अभी भी वही डेटा वापस करना चाहते हैं जो हम वर्तमान में कर रहे हैं (इसलिए एफसीसी एपीआई का उपयोग करके किसी भी पुरानी परियोजनाओं को तोड़ने के लिए नहीं)। हम केवल प्रतिक्रिया में एक अतिरिक्त संपत्ति जोड़ रहे होंगे। तुम क्या सोचते हो?

मैं डेवलपर्स को संबंधित जानकारी देने और उन्हें चुनने देने के इस विचार से पूरी तरह सहमत हूं, यह वह रास्ता है जिस पर मैं सबसे अधिक विचार कर रहा था

क्या एफसीसी परियोजनाओं में परीक्षण और अनुरोध करने के लिए मानक उपकरण हैं?
उन अनुरोधों के लिए जो मैं उपयोग कर रहा हूं (सिर्फ इसलिए कि मैंने इसे एक्सिस के बजाय एक कोशिश देने का फैसला किया है)
www.npmjs.com/package/request
परीक्षण के लिए मुझे बहुत अनुभव नहीं है लेकिन मैं मोचा के बारे में सोच रहा था।
लेकिन कृपया मुझे बताएं कि कौन से उपकरण बेहतर तरीके से एफसीसी के साथ एकीकृत हैं

एक बात मुझे निश्चित रूप से समझने के लिए कुछ मदद की ज़रूरत है, यह सुरक्षा समस्या है github मुझे इसके बारे में चेतावनी दे रही है

सबसे सरल उपाय सिर्फ npm audit fix चलना है और फिर package.json और package-lock.json अपडेट करना है। नए पैकेज में पिछले, कमजोर लोगों से कोई भी परिवर्तन नहीं होना चाहिए। हालाँकि, यह मानता है कि पैकेज लेखकों ने गलती से ब्रेकिंग परिवर्तन नहीं किया है, इसलिए फिक्स लागू होने के बाद यह मैन्युअल रूप से आपके ऐप की जाँच करने के लायक है।

मैं OpenWeather एपीआई के साथ खेल रहा हूं (वास्तव में मुझे शुरुआत से ऐसा करना चाहिए था)।
क्या हमें यह पता था? https://openweathermap.org/faq#error401
प्रासंगिक हिस्सा

FOSS डेवलपर्स के लिए: हम स्वतंत्र और मुक्त स्रोत सॉफ़्टवेयर का स्वागत करते हैं और आपकी मदद करने के लिए तैयार हैं। यदि आप अपने फ्री सॉफ्टवेयर एप्लीकेशन में OWM डेटा का उपयोग करना चाहते हैं, तो कृपया एक एपीआई कुंजी पंजीकृत करें और अपने आवेदन और एपीआई कुंजी पंजीकृत एक टिकट दर्ज करें। यदि ओपन सोर्स एप्लिकेशन में उपयोग किया जाता है तो OWM आपके कुंजी के लिए आपके अनुरोध की लिफ्ट एक्सेस सीमा की समीक्षा करेगा।

नमस्कार दोस्तों, मैं उम्मीद से अधिक विवश हो गया हूं।
अपने खाली समय पर, मैं OpenWeather एप का अध्ययन कर रहा हूं। दुर्भाग्य से यह अच्छी तरह से प्रलेखित नहीं है।
मुझे लगता है कि मैं एक संभव रणनीति के साथ आया था, बॉक्स विकल्प का उपयोग करके, लेकिन मैं अभी भी परीक्षण कर रहा हूं।
मैं अपने पास आए सभी दस्तावेजों के साथ एक दस्तावेज बनाने के इस विचार के साथ आया था, जो परीक्षण मैं कर रहा हूं।

@ Hash2C इसे ठीक करने के लिए अपना समय लें। इस बग को यहां काफी समय हो गया है।

@RandellDawson
आपको पता था कि आप क्या कह रहे थे: Heavy_check_mark:

@ Hash2C आपका समाधान कैसे आ रहा है?

इस मुद्दे को बंद करने के रूप में सामान्य रूप से इस परियोजना पर काम करने वाले उपयोगकर्ताओं की संख्या में काफी गिरावट आई है क्योंकि यह अब प्रमाणीकरण के लिए आवश्यक परियोजना नहीं है। इसके कारण कम उदाहरण हैं जहां एपीआई के लिए दर सीमा समाप्त हो गई है।