Freecodecamp: FCC Weather API gibt zufällig Japan Wetter zurück

Ich glaube, ich habe das Problem identifiziert! Es wird einfach aus dem Cache gelesen , der die japanischen Daten enthält.

Der Cache wird nur verwendet, wenn sich mehr als sechzig Anforderungen in seiner Warteschlange befinden (Zeile 50) . Dies bedeutet, dass er manchmal korrekte Ergebnisse zurückgibt. aber manchmal wird es diese unerwarteten Ergebnisse zurückgeben.

Wie kann das behoben werden? Wir haben drei Möglichkeiten ...

• Entfernen Sie den Cache
• Machen Sie den Cache funktionsfähig und verwenden Sie die Breiten- und Längengraddaten, wenn Sie entscheiden, ob Sie den Cache verwenden möchten.
  
  
  
  • Die Anfrage vollständig ablehnen, wenn sich der Server überlastet fühlt (vorerst empfohlen )
  
  

Da dies eine Hilfe ist, würde ich mir das gerne ansehen. Angesichts der Tatsache, dass dies Projekte stört und wie ich Schlaf brauche, wenn jemand dies beheben möchte (der einfachste Weg ist, den Cache zu ändern, um stattdessen Anfragen abzulehnen), dann tun Sie dies bitte!

Okay, ich glaube, ich habe das Problem behoben . Ich konnte es jedoch nicht testen, da mir ein API-Schlüssel fehlte - und es besteht natürlich das Risiko eines DOS, da wir nie auf Caching zurückgreifen.

Es könnten also Verbesserungen vorgenommen werden. Sollten wir vielleicht Anfragen ablehnen, an die wir sonst die japanischen Daten senden würden? Das liegt an euch. Ich behebe es vorübergehend und werde versuchen, es morgen besser zu machen.

Ich glaube nicht, dass ich eine Pull-Anfrage an die glitch.me-API stellen kann (es sei denn, es gibt natürlich ein Repository auf GitHub, das ich verpasst habe). Daher muss jemand mit Schreibberechtigung meine Änderungen zusammenführen, nachdem er sie mit einem funktionierenden API-Schlüssel getestet hat.

Richtig, ich bin zu diesem Zeitpunkt afk; aber ich erkannte, dass die Ratenbegrenzung erforderlich ist. Ich werde meinen Code bald korrigieren, damit Anfragen abgelehnt werden, wenn zu viele API-Aufrufe getätigt wurden.

Okay, ich denke jetzt habe ich kurzfristig eine Lösung geschaffen. Ich bin mir nicht sicher, was wir gegen die beängstigende Datenerfassung tun wollen - die Koordinaten sind in der Regel recht genau (sollten wir sie für das Zwischenspeichern von Zwecken runden?). Wir sollten auf jeden Fall Dinge markieren, wenn sie aus dem Cache stammen, um klar zu machen, dass sie nicht 100% genau sind.

Wenn der Code versucht, auf den Cache zuzugreifen, wird vorerst stattdessen eine Fehlermeldung gesendet.

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

Hi @ joker314 Ich stimme Ihrer Lösung zu, mit einem Fehler abzulehnen. Können Sie bitte eine PR machen? Vielen Dank, dass Sie sich die Zeit genommen haben, dies zu untersuchen.

@QuincyLarson Könnten Sie https://fcc-weather-api.glitch.me/ hat ? Ich kann delegiert werden, wenn Sie der Eigentümer sind.

@raisedadead Ich würde gerne, aber ich habe mich umgesehen und bin mir nicht sicher, ob glitch.me tatsächlich Pull-Anfragen unterstützt - es sei denn, Sie haben auch eine Kopie auf GitHub oder ich vermisse etwas?

EDIT: Natürlich kann der korrigierte Code auf meinem Remix gefunden werden .

@ joker314 yup du bist richtig, wir werden das Projekt von deinem Remix aktualisieren. Bitte ignorieren Sie meinen vorherigen Kommentar.

Ich warte auf Quincy, um den Zugriff auf dieses Projekt zu bestätigen. Vielen Dank für Ihre Hilfe.

@raisedadead - Wie lange wird diese vorübergehende Korrektur bestehen? Wie würde die ultimative Lösung dafür aussehen? Ist dies nur ein Problem mit dem Ratenlimit? Wenn ja, wird es nur noch schlimmer, wenn mehr Camper Wetterprojekte erstellen. Kann das Ratenlimit erhöht werden?

Wie lange wird diese vorübergehende Korrektur bestehen bleiben?

Dies ist nicht vorübergehend. Mit dem Fehler wird bekannt, dass das Problem auf die Ratenbeschränkungen zurückzuführen ist.

Dies war ein Wrapper, der auf der OpenWeatherMaps-API erstellt wurde, der meiner Meinung nach kein https unterstützt und daher mit dem Codepen in Konflikt steht.

Wenn ja, wird es nur noch schlimmer, wenn mehr Camper Wetterprojekte erstellen. Kann das Ratenlimit erhöht werden?

Ja, Sie können sich für eine kostenpflichtige Version entscheiden, indem Sie die API direkt anstelle des Glitch Wrappers in die Herausforderung integrieren.

Siehe https://openweathermap.org/price

@raisedadead Es sieht aus wie der ursprüngliche Code, der für einen Cache vorgesehen ist. Wenn dies der Fall ist und wir die Details dahingehend glätten können, wie dies genau aussehen soll, um die Privatsphäre zu respektieren, können wir hoffentlich die Ratenbegrenzung umgehen?

Beim zweiten Gedanken ist es vielleicht am besten, gültige Daten anstelle einer Fehlermeldung zurückzugeben. Ändern wir stattdessen den Cache, um zufällige Wetterbedingungen zu generieren, und setzen Sie den Speicherort auf "API belegt, versuchen Sie es später erneut, um echte Ergebnisse zu erzielen".

Was denkst du darüber, @raisedadead?

Als jemand, der gerade dieses Projekt abgeschlossen hat und das Problem hatte, japanische Wetterdaten oder (meistens) keine Daten zu erhalten, möchte ich sagen, dass das Empfangen von Daten nützlicher ist als keine Daten. Zumindest mit den japanischen Daten konnte ich sehen, ob mein Code funktioniert, unabhängig davon, ob er genaues Wetter anzeigt.

Theoretisch könnten wir zufällige Daten senden. Wir möchten jedoch keine Beschwerden über falsche Daten erhalten. Ich bin mir ziemlich sicher, dass dies der Fall sein wird.

Wie auch immer, wenn es hilft, lassen Sie uns die zufälligen Daten haben.

@QuincyLarson können Sie bitte mit der obigen Anfrage führen ?

Ich denke, wir sollten gefälschte Daten senden, aber klarstellen, dass es sich um gefälschte Daten handelt. Der Standortname muss "API Busy, Fake Data" sein und das Wetter, die Koordinaten usw. müssen in der Antwort zufällig ausgewählt werden. Auf diese Weise wissen die Leute, warum die Ergebnisse nicht genau sind. und dennoch wird alles für Entwickler funktionieren.

Gedanken?

Wenn Sie gefälschte Daten senden, würde dies meines Erachtens den gesamten Zweck der Bereitstellung der aktuellen Wetterdaten für einen bestimmten Standort zunichte machen. Ich mag die Idee von @ joker314 , herauszufinden, wie wir den Cache erstellen und implementieren möchten.

Würden Sie in Betracht ziehen, die jüngsten Forumsdiskussionen auf der Projektseite festzuhalten, damit die Programmierer wissen, dass es Probleme mit dem Projekt gibt, und keine unnötige Zeit damit verbringen, etwas zu beheben, über das sie keine Kontrolle haben?

Übrigens, ich denke, die Bild-URL von icon wird nicht zurückgegeben, wie in https://fcc-weather-api.glitch.me/ beschrieben.
Es hieß Images links are included in the JSON under weather[0].icon , was nicht der
Ich habe festgestellt, dass die Demo-Lösung CSS geschrieben hat, um das Symbol zu zeichnen.

Vielen Dank, dass Sie uns über dieses potenzielle Problem informiert haben. Die Beispielanforderung und die Antwort enthalten jedoch das gewünschte Feld. Welche spezielle Anfrage haben Sie gestellt, die dieses Feld nicht hatte?

@ joker314 Danke für die Antwort.

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}

Ich habe nicht bemerkt, dass das Beispiel gut funktioniert, also könnte dies an der Lage oder dem besonderen Wetter liegen?

@ Em-Ant Es sieht so aus, als ob dies ein Problem mit der App ist, die auf Glitch ausgeführt wird. Könnten Sie einen Blick in den Cache werfen und sehen, ob dies etwas ist, das wir löschen können?

Ich habe einige schnelle Tests durchgeführt, ich glaube, das ist behoben. Wenn immer noch Probleme auftreten, können Sie dieses Problem erneut öffnen.

@ moT01 Was für Tests hast du gemacht? Das Problem ist, dass es ein Ratenlimit für das kostenlose FCC-Konto gibt, mit dem die OpenWeather-API aufgerufen wird. Sobald diese Ratenlimits erreicht sind, gibt der Glitch-Proxy die Japan-Koordinaten zurück. Der einzige Grund, warum es derzeit nicht als Problem angesehen wird, ist, dass dieses Projekt jetzt im Lehrplan optional ist, sodass es nicht mehr so ​​viele Treffer gibt wie früher. Sobald Sie den Glitch 60 Mal in einer Minute treffen, wird der folgende JSON zurückgegeben:

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

Können Sie dieses Problem erneut öffnen, da es immer noch auf meiner Aufgabenliste der zu behebenden Projekte steht?

Ahh, ja - ich habe gerade ein paar kurze Anrufe bei der API getätigt und konnte das richtige Wetter ermitteln. Ich nehme an, ich sollte mich wahrscheinlich etwas mehr erkundigen, bevor ich Probleme schließe.

Ich habe gleich zu Beginn des Hacktoberfestes angefangen, an einem Fix zu arbeiten, und mich dann intensiv mit dem QS-Prozess befasst. Der Rest ist Geschichte. Ich muss das noch einmal überdenken, denn jetzt habe ich ein viel besseres Verständnis von Node und Express, um eine funktionierende Lösung in Gang zu bringen.

Es gibt einen statischen Cache mit nur einem Eintrag (dem Speicherort in Japan).

Wir könnten das Problem beheben, indem wir den Ratenbegrenzer entfernen (ich weiß nicht, ob es eine gute Idee ist, da wir dort nur einen API-Schlüssel haben) oder einen Ratenlimitfehler zurückgeben, falls wir das Anforderungskontingent überschreiten.

Wie auch immer, dieses API-Projekt auf Glitch gehört @MiloATH , und wir können es nicht bearbeiten, ohne es zu "forken", dh eine neue App mit einer neuen URL zu erstellen.

Ich habe eine Beitrittsanfrage unter https://glitch.com/edit/#!/fcc -weather-api über das Camperbot-Konto an Milo gesendet.

Das klingt nach guten Ideen! Es gibt eine dritte Option; den Cache so zu reparieren, dass dort tatsächlich Daten gespeichert werden - oder zufällige Daten zu senden, wenn der Ratenbegrenzer getroffen wird.

Ich befürchte, dass das Überschreiten des Ratenlimits keine gute Idee ist, da der API-Schlüssel unter solchen Umständen widerrufen werden könnte und wir möglicherweise auf keinen Fall Ergebnisse von der API erhalten.

@ joker314 Ich

Ich habe eine Einladung zum Glitch-Projekt weitergeleitet.

Der Endpunkt könnte deutlich besser sein. Ich denke, wir sollten ein separates Repo mit CI erstellen und auf etwas Reiferem wie Heroku (kostenlose Version) bereitstellen. Dies würde es uns ermöglichen, leichter an dem Projekt zu arbeiten.

Wir werden nicht mehr für Heroku eingesetzt. Wir werden Glitch vorerst verwenden. Das heißt, wenn es ein alternatives Projekt gibt, stellen wir es gerne unter dem Konto von freeCodeCamp auf Glitch bereit und ersetzen die vorhandene Herausforderung im Lehrplan

@raisedadead @RandellDawson
Hallo! Irgendwelche Updates dazu?
Es wäre fantastisch, einige Diagramme mit der Architektur und dem Datenfluss (und schließlich den zugehörigen Dateinamen) zu sehen.

@ Hash2C Sie können das vorhandene Glitch-Projekt (siehe unten) neu anzuzeigen und zu reparieren.

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

Danke @RandellDawson , ich habe daran gearbeitet, ich hoffe, ich kann einen ersten Entwurf bis Donnerstag fertigstellen

@ Hash2C Nehmen Sie sich Zeit, um es richtig zu machen. Dieser Fehler ist schon seit einiger Zeit hier.

Danke @RandellDawson , ich werde mein Bestes geben.
Ich muss ein bisschen mehr über die aktuellen Einschränkungen wissen.
Ich habe oben gelesen, dass wir ein Limit von 60 Treffern pro Minute haben, was die kostenlose Stufe bei OpenWeather-Preisen zu sein scheint. Gibt es eine Möglichkeit, diese Grenze zu erhöhen? Möchten Sie andere Abonnements für OW erstellen? Gibt es andere freie "Quellen der Wahrheit", die wir zusammen mit OW nutzen könnten?

Bearbeiten: Auch welche Art von Verzögerung wäre akzeptabel zu liefern? 5 Minuten? 15 Minuten? 1h? 3h?

Edit2: Es scheint, dass OW "Weather API Data Update" "<2 Stunden" ist, wie in dieser Tabelle gezeigt
https://openweathermap.org/price
Aus derselben Tabelle geht hervor, dass die Verfügbarkeit nur 95% beträgt

Gibt es eine Möglichkeit, diese Grenze zu erhöhen? Möchten Sie andere Abonnements für OW erstellen?

Möglicherweise sind auch die IP-Adressen begrenzt (nicht sicher), sodass das Erstellen anderer Abonnements nicht hilfreich ist.

Gibt es andere freie "Quellen der Wahrheit", die wir zusammen mit OW nutzen könnten?

Nicht sicher.

Edit2: Es scheint, dass OW "Weather API Data Update" "<2 Stunden" ist, wie in dieser Tabelle gezeigt

Ich entwickle derzeit mein eigenes Wetterprojekt mit der kostenlosen Version von OpenWeather und habe überlegt, nur zu überprüfen, ob die Anfrage weniger als 10 Minuten von der letzten Anfrage entfernt ist, und dann die zuletzt zurückgegebenen Daten für denselben Lat / Lon anzuzeigen.

Ich denke, wir können auch die Anweisungen der Herausforderung aktualisieren, um den Entwickler darüber zu informieren, dass wir eine spezielle Antwort zurücksenden, wenn ein Limit erreicht ist, damit ein App-Benutzer wissen kann, dass die Daten möglicherweise nicht aktuell sind. Wir möchten immer noch die gleichen Daten zurückgeben, die wir derzeit sind (um keine alten Projekte mit der FCC-API zu beschädigen). Wir würden der Antwort nur eine zusätzliche Eigenschaft hinzufügen. Was denken Sie?

Ich habe dieses Repo erstellt, damit es einfacher ist, es lokal zu testen.
https://github.com/Hash2C/fccWeatherApiDraft

Ich glaube, die 3 Hauptanwendungsfälle (vorerst) sind bereits abgedeckt

• Wenn die Koordinaten ungültig / nicht vorhanden sind, senden Sie einen Fehler
  Andernfalls konvertieren Sie die Koordinaten in ein praktisches Format, und dann versuchen wir, den Cache zu erreichen

• Wenn die angeforderten Koordinaten zwischengespeichert werden
  
  
  
  • Wenn der Zeitstempel innerhalb des akzeptablen Deltas liegt: zwischengespeicherte Daten senden (1)
  
  
  • sonst: Verspottungsdaten als zwischengespeicherte Daten festlegen (falls der spätere OpenWeather-API-Aufruf fehlschlägt)
  
  

• sonst: Verspottungsdaten als etwas festlegen, das wir entscheiden (falls der spätere OpenWeather-API-Aufruf fehlschlägt).

• Wir versuchen OpenWeather API aufzurufen.

• Wenn wir die richtigen Daten erhalten, senden Sie sie und speichern Sie sie im Cache (2).
• Andernfalls senden Sie die Spottdaten (3)

Dieser Fluss ist natürlich sehr offen für Diskussionen!

Es gibt noch viel zu tun, Validierungen, asynchrone Dinge, Randfälle (Tests) usw., aber wir werden nach und nach dorthin gelangen. Ich habe die server.js -Datei oft kommentiert (keine Angst). Ich werde die meisten dieser Informationen nach und nach filtern und Sie hier um Hilfe bitten, damit wir jedes Problem diskutieren können.

Nur eine Idee: Könnten wir irgendwann einen Datendienst haben, der versucht, die Anzahl der "verfügbaren Anforderungen an die OpenWeather-API (oder andere), die nicht gestellt werden" zu minimieren? Dieser Dienst würde beispielsweise eine MongoDB-Datenbank speisen - das wäre unser Cache (wir könnten Memcached verwenden, aber das ist wahrscheinlich zu viel, wir brauchen diese zusätzliche Geschwindigkeit nicht).

Andere Ideen: Gibt es frühere Nutzungsstatistiken für diesen Dienst? Wenn nicht, könnten wir vielleicht anfangen, eine zu erstellen, vielleicht könnte das nützlich sein, um zu versuchen, eine eventuell mögliche, aber sehr suboptimale Lösung zu optimieren

Eine Sache, die ich sicherlich brauchen werde, um zu verstehen, ist diese Sicherheitsprobleme, vor denen mich Github warnt

(Aus irgendeinem Grund habe ich deine Nachricht total verpasst!)

Möglicherweise sind auch die IP-Adressen begrenzt (nicht sicher), sodass das Erstellen anderer Abonnements nicht hilfreich ist.

Guter Punkt. Lohnt es sich zu testen?

Gibt es andere freie "Quellen der Wahrheit", die wir zusammen mit OW nutzen könnten?

Nicht sicher.

Wenn wir dies tun dürfen, kann dies die Wahrscheinlichkeit einer erfolgreichen Lösung erheblich erhöhen.

Ich entwickle derzeit mein eigenes Wetterprojekt mit der kostenlosen Version von OpenWeather und habe überlegt, nur zu überprüfen, ob die Anfrage weniger als 10 Minuten von der letzten Anfrage entfernt ist, und dann die zuletzt zurückgegebenen Daten für denselben Lat / Lon anzuzeigen.

Ja, zwischengespeicherte Daten verwenden, oder? Ich habe diese <2-stündige Frage gestellt, weil ich zuvor nach der akzeptablen Verzögerung gefragt habe. Je länger die Verzögerung, desto besser, sodass wir mehr in den Cache gelangen und die API nicht so oft aufrufen müssen. Begann mit der Codierung, vorausgesetzt, wir können Daten senden, die höchstens 1 Stunde alt sind, um sie zu starten.

Ich denke, wir können auch die Anweisungen der Herausforderung aktualisieren, um den Entwickler darüber zu informieren, dass wir eine spezielle Antwort zurücksenden, wenn ein Limit erreicht ist, damit ein App-Benutzer wissen kann, dass die Daten möglicherweise nicht aktuell sind. Wir möchten immer noch die gleichen Daten zurückgeben, die wir derzeit sind (um keine alten Projekte mit der FCC-API zu beschädigen). Wir würden der Antwort nur eine zusätzliche Eigenschaft hinzufügen. Was denken Sie?

Ich stimme dieser Idee voll und ganz zu, den Entwicklern die relevanten Informationen zu geben und sie wählen zu lassen. Dies ist der Weg, den ich auch für den angemessensten hielt

Gibt es Standardwerkzeuge zum Testen und zum Stellen von Anfragen in FCC-Projekten?
Für Anfragen, die ich verwende (nur weil ich beschlossen habe, es anstelle von Axios auszuprobieren)
www.npmjs.com/package/request
Zum Testen habe ich nicht viel Erfahrung, aber ich habe an Mokka gedacht.
Aber bitte lassen Sie mich wissen, welche Tools besser in FCC integriert werden können

Eine Sache, die ich sicherlich brauchen werde, um zu verstehen, ist diese Sicherheitsprobleme, vor denen mich Github warnt

Die einfachste Lösung besteht darin, npm audit fix auszuführen und dann die aktualisierten package.json und package-lock.json . Die neuen Pakete sollten keine wesentlichen Änderungen gegenüber den vorherigen, anfälligen Paketen aufweisen. Dies setzt jedoch voraus, dass die Paketautoren nicht versehentlich eine wichtige Änderung vorgenommen haben. Es lohnt sich daher, Ihre App manuell zu überprüfen, nachdem die Korrekturen angewendet wurden.

Ich habe mit der OpenWeather-API gespielt (eigentlich hätte ich das von Anfang an tun sollen).
Wussten wir das? https://openweathermap.org/faq#error401
Der relevante Teil

Für FOSS-Entwickler: Wir begrüßen kostenlose Open-Source-Software und helfen Ihnen gerne weiter. Wenn Sie OWM-Daten in Ihrer kostenlosen Softwareanwendung verwenden möchten, registrieren Sie bitte einen API-Schlüssel und reichen Sie ein Ticket ein, das Ihre Anwendung und den registrierten API-Schlüssel beschreibt. OWM überprüft die Zugriffsbeschränkungen für Ihren Schlüssel für Ihren Schlüssel, wenn dieser in Open Source-Anwendungen verwendet wird.

Hallo Leute, ich war gezwungener als erwartet.
In meiner Freizeit habe ich die OpenWeather-API studiert. Leider ist es nicht gut dokumentiert.
Ich glaube, ich habe mit der Option bbox eine praktikable Strategie entwickelt, aber ich teste immer noch.
Ich hatte die Idee, ein Dokument mit allen Informationen zu erstellen, auf die ich gestoßen bin, den Tests, die ich mache.

@ Hash2C Nehmen Sie sich Zeit, um es richtig zu machen. Dieser Fehler ist schon seit einiger Zeit hier.

@ RandellDawson
Sie wussten, was Sie sagten: heavy_check_mark:

@ Hash2C Wie kommt deine Lösung

Das Schließen dieses Problems, da die Anzahl der Benutzer, die an diesem Projekt arbeiten, im Allgemeinen erheblich gesunken ist, da es für eine Zertifizierung nicht mehr erforderlich ist. Dies hat zu weniger Fällen geführt, in denen das Ratenlimit für die API erreicht ist.