Freecodecamp: L'API Météo FCC renvoie la météo au Japon au hasard

Je pense avoir identifié le problème! Il s'agit simplement de lire à partir du cache , qui contient les données japonaises.

Le cache n'est utilisé que s'il y a plus de soixante requêtes dans sa file d'attente (ligne 50) Cela signifie que _parfois_ il retournera des résultats corrects; mais _parfois_ il renverra ces résultats inattendus.

Comment cela peut-il être résolu? Nous avons trois options ...

• Supprimer le cache
• Rendez le cache fonctionnel et utilisez réellement les données de latitude et de longitude pour décider d'utiliser le cache.
  
  
  
  • Rejeter complètement la demande si le serveur se sent surchargé ( recommandé pour l'instant )
  
  

Puisqu'il s'agit d'un besoin d'aide, j'adorerais jeter un œil à ceci; Cependant, étant donné que cela perturbe les projets et que j'ai besoin de dormir, si quelqu'un veut résoudre ce problème (le moyen le plus simple est de changer le cache pour rejeter les demandes), alors faites-le!

D'accord, je pense que j'ai résolu le problème . Je n'ai pas pu le tester, car je n'avais pas de clé API - et il y a bien sûr le risque d'un DOS étant donné que nous n'avons jamais recours à la mise en cache.

Ainsi, des améliorations pourraient être apportées. Devrions-nous, peut-être, rejeter les demandes là où nous enverrions autrement les données japonaises? C'est à vous de décider. Je le répare temporairement et j'essaierai de l'améliorer demain.

Je ne pense pas que je puisse faire une pull request à l'API glitch.me (à moins, bien sûr, qu'il y ait un référentiel sur GitHub que j'ai manqué); donc une personne disposant d'une autorisation en écriture devra fusionner mes modifications après les avoir testées avec une clé API fonctionnelle.

Bon, je suis foutu en ce moment; mais j'ai réalisé que la limitation de débit est nécessaire. Je corrigerai bientôt mon code afin que les demandes soient refusées si trop d'appels d'API ont été effectués.

D'accord, je pense maintenant avoir créé une solution à court terme. Je ne suis pas sûr de ce que nous voulons faire à propos de la collecte de données effrayante - les coordonnées ont tendance à être assez précises (devrions-nous les arrondir pour les achats en cache?). Nous devons absolument marquer les choses si elles proviennent du cache, pour que cela ne soit pas précis à 100%.

Quoi qu'il en soit, pour l'instant, chaque fois que le code essaie d'accéder au cache, il enverra à la place un message d'erreur.

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

Salut @ joker314 J'accepte votre solution de rejet avec une erreur. Pouvez-vous s'il vous plaît faire un PR? Merci beaucoup d'avoir pris le temps d'enquêter là-dessus.

@QuincyLarson pourriez-vous guider qui a accès à ce https://fcc-weather-api.glitch.me/ ? Je peux être délégué si vous êtes le propriétaire.

@raisedadead J'adorerais, mais j'ai regardé autour de moi et je ne suis pas sûr si glitch.me prend réellement en charge les pull requests - à moins que vous n'en ayez également une copie sur GitHub ou qu'il me manque quelque chose?

EDIT: Bien sûr, le code corrigé se trouve sur mon remix .

@ joker314 oui vous avez raison, nous mettrons à jour le projet à partir de votre remix. Veuillez ignorer mon commentaire précédent.

J'attends Quincy la confirmation de l'accès à ce projet. Merci beaucoup pour votre aide.

@raisedadead -

Alors, combien de temps ce correctif temporaire sera-t-il en place?

Ce ne sera pas temporaire, avec l'erreur, on saura que le problème est dû aux limites de taux.

Il s'agissait d'un wrapper créé au-dessus de l'API OpenWeatherMaps, qui ne supportait pas https je pense, et donc en conflit avec codepen.

Si tel est le cas, cela ne fera qu'empirer à mesure que de plus en plus de campeurs créeront des projets météorologiques. Le taux limite peut-il être augmenté?

Oui, vous pouvez opter pour une version payante en intégrant directement l'API au lieu du wrapper glitch dans le défi.

Voir https://openweathermap.org/price

@raisedadead Il ressemble au code original destiné à y avoir un cache. Si tel est le cas, et si nous pouvons clarifier les détails sur ce à quoi nous voulons que cela ressemble pour respecter la vie privée, alors espérons que nous pourrons contourner la limitation de débit?

Après réflexion, il est peut-être préférable de renvoyer des données valides au lieu d'un message d'erreur. Modifions plutôt le cache pour générer des conditions météorologiques aléatoires, et définissons l'emplacement sur "API occupée, réessayez plus tard pour de vrais résultats"?

Que pensez-vous de cela, @raisedadead?

En tant que personne qui vient de terminer ce projet et qui a eu le problème de recevoir des données météorologiques japonaises ou (la plupart du temps) aucune donnée, je voudrais dire que recevoir des données est plus utile que pas de données. Au moins avec les données japonaises, je pouvais voir si mon code fonctionnait indépendamment du fait qu'il montre une météo précise.

Eh bien en théorie, nous pourrions envoyer des données aléatoires. Mais nous ne voulons pas recevoir de plaintes sur les données incorrectes ... ce qui, je suis sûr, sera un cas.

Quoi qu'il en soit, si cela aide permet d'avoir les données aléatoires.

@QuincyLarson pouvez-vous s'il vous plaît guider avec la demande ci-dessus ?

Je pense que nous devrions envoyer de fausses données, mais dites clairement que ce sont des fausses Faites en sorte que le nom de l'emplacement soit «API occupé, fausses données» et que la météo, les coordonnées, etc. soient randomisées dans la réponse. De cette façon, les gens savent pourquoi les résultats ne sont pas précis; et pourtant tout fonctionnera toujours pour les développeurs.

Pensées?

Si vous envoyez de fausses données, je pense que cela irait à l'encontre de l'objectif de fournir les données météorologiques actuelles pour un emplacement spécifique. J'aime l'idée de @ joker314 de déterminer comment nous voulons créer le cache et l'implémenter.

Pensez-vous à épingler les discussions récentes du forum sur la page du projet afin que les codeurs sachent qu'il y a des problèmes avec le projet et ne passent pas de temps inutile à essayer de résoudre quelque chose qu'ils n'ont pas de contrôle?

BTW, je pense que l'url d'image du icon n'est pas retournée comme décrit dans https://fcc-weather-api.glitch.me/.
Il disait Images links are included in the JSON under weather[0].icon , ce qui ne l'est pas.
J'ai remarqué que la solution de démonstration écrivait css pour dessiner l'icône.

Merci de nous avoir fait part de ce problème potentiel, mais l'exemple de demande et de réponse inclut le champ souhaité. Quelle demande particulière avez-vous faite sans ce champ?

@ joker314 Merci d' avoir répondu.

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}

Je n'ai pas remarqué que l'exemple fonctionnait bien, donc je suppose que cela pourrait être dû à l'emplacement ou à la météo particulière?

@ Em-Ant Il semble que ce soit un problème avec l'application exécutée sur Glitch. Pourriez-vous jeter un œil au cache et voir si c'est quelque chose que nous pouvons effacer?

J'ai fait quelques tests rapides, je pense que c'est corrigé. Si quelqu'un rencontre toujours des problèmes, n'hésitez pas à rouvrir ce numéro.

@ moT01 Quel genre de tests avez-vous fait? Le problème est qu'il existe une limite de taux par compte FCC gratuit utilisé pour passer des appels vers l'API OpenWeather. Une fois ces limites de taux atteintes, le proxy Glitch renvoie les coordonnées du Japon. La seule raison pour laquelle il n'est pas considéré comme un problème pour le moment, c'est que ce projet est désormais facultatif dans le programme, de sorte qu'il n'y a pas autant de succès qu'il y en avait auparavant. Dès que vous atteignez le Glitch 60 fois en une minute, le JSON suivant est renvoyé:

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

Pouvez-vous rouvrir ce problème, car il figure toujours dans ma liste de tâches à résoudre?

Ahh, oui - je viens de passer quelques appels rapides à l'API et j'ai pu obtenir la météo correcte. Je suppose que je devrais probablement m'enquérir un peu plus avant de clôturer les problèmes.

J'ai commencé à travailler sur un correctif dès le début de Hacktoberfest, puis je me suis fortement impliqué dans le processus d'assurance qualité. Le reste appartient à l'histoire. Je dois revoir cela à nouveau, car maintenant j'ai une bien meilleure compréhension de Node et Express pour pouvoir mettre en place une solution fonctionnelle.

Il existe un cache statique qui n'a qu'une seule entrée (l'emplacement au Japon).

Nous pourrions le réparer en supprimant le limiteur de débit (je ne sais pas si c'est une bonne idée, car nous n'avons qu'une seule clé API), ou renvoyer une erreur de limite de taux au cas où nous dépasserions le quota de demandes.

Quoi qu'il en soit, ce projet api sur glitch appartient à @MiloATH , et nous ne pouvons pas le modifier sans le «forger», c'est-à-dire créer une nouvelle application avec une nouvelle URL.

J'ai envoyé une demande d'adhésion sur https://glitch.com/edit/#!/fcc -weather-api en utilisant le compte camperbot à Milo.

Cela ressemble à de bonnes idées! Il y a une troisième option; pour réparer le cache afin que les données y soient réellement stockées - ou pour envoyer des données aléatoires si le limiteur de débit est touché.

Je crains que le dépassement de la limite de débit ne soit pas une bonne idée car la clé API pourrait être révoquée dans de telles circonstances, et nous pourrions ne pas obtenir de résultats de l'API dans tous les cas.

@ joker314 J'allais déjà dans la direction de votre troisième option.

J'ai transmis une invitation au projet glitch.

Le point final pourrait être nettement meilleur. Je pense que nous devrions construire un repo séparé avec CI et déployer sur quelque chose de plus mature comme Heroku (version gratuite). Cela nous permettrait de travailler plus facilement sur le projet.

Nous ne déployons plus sur heroku. Nous allons utiliser Glitch pour le moment. Cela signifie que s'il existe un projet alternatif, nous sommes heureux de le déployer sous le compte de freeCodeCamp sur Glitch et de remplacer le défi existant dans le programme.

@raisedadead @RandellDawson
Salut! Des mises à jour à ce sujet?
Ce serait génial de voir quelques diagrammes avec l'architecture et le flux de données (et éventuellement les noms de fichiers associés)

@ Hash2C Vous pouvez remixer le projet Glitch existant (illustré ci-dessous) pour voir et corriger le projet.

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

Merci @RandellDawson , j'y ai travaillé, j'espère pouvoir terminer un premier brouillon jusqu'à jeudi

@ Hash2C Prenez votre temps pour bien faire les choses. Ce bogue est là depuis un certain temps.

Merci @RandellDawson , je ferai de mon mieux.
Je vais avoir besoin d'en savoir un peu plus sur les contraintes actuelles.
J'ai lu ci-dessus que nous avons une limite de 60 visites par minute, ce qui semble être le niveau gratuit de la tarification OpenWeather. Existe-t-il un moyen d'augmenter cette limite? Vous aimez créer d'autres abonnements à OW? Existe-t-il d'autres «sources de vérité» gratuites que nous pourrions utiliser avec OW?

Edit: De plus, quel type de retard serait acceptable à livrer? 5min? 15 minutes? 1h? 3h?

Edit2: Il semble que OW "Mise à jour des données de l'API météo" est "<2 heures" comme indiqué dans ce tableau
https://openweathermap.org/price
Le même tableau nous indique que la disponibilité n'est que de 95%

Existe-t-il un moyen d'augmenter cette limite? Vous aimez créer d'autres abonnements à OW?

Ils peuvent également avoir des limites sur l'adresse IP (pas sûr), donc la création d'autres abonnements ne serait pas utile.

Existe-t-il d'autres «sources de vérité» gratuites que nous pourrions utiliser avec OW?

Pas sur.

Edit2: Il semble que OW "Mise à jour des données de l'API météo" est "<2 heures" comme indiqué dans ce tableau

Je développe actuellement mon propre projet météo en utilisant la version gratuite d'OpenWeather et j'ai envisagé de simplement vérifier si la requête est à moins de 10 minutes de la dernière requête, puis d'afficher les dernières données renvoyées pour le même lat / lon.

Je pense que nous pouvons également mettre à jour les instructions du défi pour informer le développeur que nous renverrons une réponse spéciale si une limite est atteinte, afin qu'il puisse informer l'utilisateur de l'application que les données ne sont peut-être pas à jour. Nous voudrions toujours renvoyer les mêmes données que nous sommes actuellement (afin de ne pas casser les anciens projets en utilisant l'API FCC). Nous ajouterions simplement une propriété supplémentaire à la réponse. Qu'est-ce que tu penses?

J'ai créé ce référentiel pour qu'il soit plus facile de tester localement.
https://github.com/Hash2C/fccWeatherApiDraft

Je pense que les 3 principaux cas d'utilisation (pour l'instant) sont déjà couverts

• Si les coordonnées sont invalides / inexistantes, envoyez une erreur
  sinon, convertissez les coordonnées dans un format pratique, puis nous essayons d'atteindre le cache

• Si les coordonnées demandées sont mises en cache
  
  
  
  • Si l'horodatage est dans le delta acceptable: envoyer les données mises en cache (1)
  
  
  • else: définissez les données simulées en tant que données mises en cache (en cas d'échec ultérieur de l'appel d'API OpenWeather)
  
  

• else: définissez les données simulées comme quelque chose que nous décidons (en cas d'échec ultérieur de l'appel à l'API OpenWeather).

• Nous essayons d'appeler l'API OpenWeather.

• Si nous obtenons les bonnes données, envoyez-les, stockez-les dans le cache (2)
• Sinon, envoyez les données moqueuses (3)

Ce flux est bien entendu extrêmement ouvert à la discussion!

Il y a encore beaucoup de travail à faire, des validations, des trucs asynchrones, des cas limites (tests), etc. mais nous y arriverons progressivement. J'ai beaucoup commenté le fichier server.js (ne soyez pas effrayant), je vais progressivement filtrer la plupart de ces informations et vous demander de l'aide ici afin que nous puissions discuter de chaque problème.

Juste une idée: pourrions-nous éventuellement avoir un service de données, qui essaie de minimiser le nombre de "requêtes disponibles à l'API OpenWeather (ou autres) qui ne sont pas effectuées"? Ce service alimenterait, disons, une base de données MongoDB - ce serait notre cache (nous pourrions utiliser Memcached mais c'est probablement trop, nous n'avons pas besoin de cette vitesse supplémentaire)

Autre idée: Existe-t-il des statistiques d'utilisation passée de ce service? Sinon, peut-être pourrions-nous commencer à en créer une, peut-être que cela pourrait être utile, pour essayer d'optimiser une solution éventuellement possible mais très sous-optimale

Une chose que j'aurai sûrement besoin d'aide pour comprendre est ce problème de sécurité que github me met en garde

(pour une raison quelconque, j'ai totalement manqué votre message!)

Ils peuvent également avoir des limites sur l'adresse IP (pas sûr), donc la création d'autres abonnements ne serait pas utile.

Bon point. Vaut-il la peine d'être testé?

Existe-t-il d'autres «sources de vérité» gratuites que nous pourrions utiliser avec OW?

Pas sur.

Si nous sommes autorisés à le faire, cela peut augmenter considérablement la probabilité de parvenir à une solution réussie.

Je développe actuellement mon propre projet météo en utilisant la version gratuite d'OpenWeather et j'ai envisagé de simplement vérifier si la requête est à moins de 10 minutes de la dernière requête, puis d'afficher les dernières données renvoyées pour le même lat / lon.

Oui, en utilisant les données mises en cache, n'est-ce pas? J'ai posé cette question <2h parce que j'avais déjà posé une question sur le délai acceptable. Plus le délai est long, mieux c'est, donc nous touchons plus le cache et nous n'avons pas à appeler l'API si souvent. Début du codage en supposant que nous pouvons réussir à envoyer des données datant d'au plus 1 h, juste pour commencer.

Je pense que nous pouvons également mettre à jour les instructions du défi pour informer le développeur que nous renverrons une réponse spéciale si une limite est atteinte, afin qu'il puisse informer l'utilisateur de l'application que les données ne sont peut-être pas à jour. Nous voudrions toujours renvoyer les mêmes données que nous sommes actuellement (afin de ne pas casser les anciens projets en utilisant l'API FCC). Nous ajouterions simplement une propriété supplémentaire à la réponse. Qu'est-ce que tu penses?

Je suis totalement d'accord avec cette idée de donner les informations pertinentes aux développeurs et de les laisser choisir, c'est le chemin que je considérais comme le plus adéquat aussi

Existe-t-il des outils standard pour tester et faire des demandes dans les projets FCC?
Pour les demandes que j'utilise (juste parce que j'ai décidé de l'essayer, au lieu d'Axios)
www.npmjs.com/package/request
Pour les tests, je n'ai pas beaucoup d'expérience mais je pensais à Mocha.
Mais faites-moi savoir quels outils s'intègrent le mieux à FCC

Une chose que j'aurai sûrement besoin d'aide pour comprendre est ce problème de sécurité que github me met en garde

La solution la plus simple consiste simplement à exécuter npm audit fix , puis à valider les mises package.json jour package-lock.json . Les nouveaux paquets ne devraient pas avoir de changements de rupture par rapport aux précédents, vulnérables. Cependant, cela suppose que les auteurs du package n'ont pas accidentellement introduit une modification de rupture, il vaut donc la peine de vérifier manuellement votre application une fois les correctifs appliqués.

J'ai joué avec l'api OpenWeather (en fait j'aurais dû le faire depuis le début).
Savions-nous cela? https://openweathermap.org/faq#error401
La partie pertinente

Pour les développeurs FOSS: nous accueillons les logiciels libres et open source et sommes prêts à vous aider. Si vous souhaitez utiliser les données OWM dans votre application logicielle gratuite, veuillez enregistrer une clé API et déposer un ticket décrivant votre application et la clé API enregistrée. OWM examinera vos limites d'accès de levée de demande pour votre clé si elle est utilisée dans une application open source.

Bonjour les gars, j'ai été plus contraint que prévu.
Pendant mon temps libre, j'ai étudié l'API OpenWeather. Malheureusement, ce n'est pas bien documenté.
Je pense que j'ai trouvé une stratégie réalisable, en utilisant l'option bbox, mais je suis toujours en train de tester.
J'ai eu l'idée de créer un document avec toutes les informations que j'ai rencontrées, les tests que je fais.

@ Hash2C Prenez votre temps pour bien faire les choses. Ce bogue est là depuis un certain temps.

@RandellDawson
Vous saviez ce que vous disiez: heavy_check_mark:

@ Hash2C Comment votre solution

Clôturer ce problème car le nombre d'utilisateurs travaillant sur ce projet en général a considérablement diminué car il ne s'agit plus d'un projet requis pour une certification. Cela a conduit à moins d'instances où la limite de débit pour l'API est atteinte.