Freecodecamp: API meteorológica de la FCC que muestra el tiempo de Japón de forma aleatoria

¡Creo que he identificado el problema! Es simplemente leer del caché , que contiene los datos japoneses.

La caché solo se usa si hay más de sesenta solicitudes en su cola (línea 50). Eso significa que _a veces_ devolverá resultados correctos; pero, a veces, devolverá estos resultados inesperados.

¿Cómo se puede arreglar esto? Tenemos tres opciones ...

• Quitar la caché
• Haga que la caché sea funcional y, de hecho, utilice los datos de latitud y longitud al decidir si utilizar la caché.
  
  
  
  • Rechace la solicitud por completo si el servidor se siente sobrecargado ( recomendado por ahora )
  
  

Dado que se trata de una solicitud de ayuda, me encantaría echarle un vistazo a esto; sin embargo, dado que esto está interrumpiendo los proyectos, y dado que necesito dormir, si alguien quiere arreglar esto (la forma más fácil es cambiar la caché para rechazar solicitudes), ¡hágalo!

Bien, creo que solucioné el problema . Sin embargo, no pude probarlo porque carecía de una clave API y, por supuesto, existe el riesgo de un DOS dado que nunca recurrimos al almacenamiento en caché.

Entonces, se podrían hacer mejoras. ¿Deberíamos, quizás, rechazar las solicitudes a las que, de lo contrario, estaríamos enviando los datos japoneses? Esto depende de todos ustedes. Lo arreglo temporalmente e intentaré trabajar para mejorarlo mañana.

No creo que pueda hacer una solicitud de extracción a la API glitch.me (a menos que, por supuesto, haya un repositorio en GitHub que me perdí); por lo que alguien con permiso de escritura deberá fusionar mis cambios después de probarlos con una clave de API que funcione.

Bien, estoy afk en este momento; pero me di cuenta de que se requiere la limitación de velocidad. Arreglaré mi código pronto para que se denieguen las solicitudes si se han realizado demasiadas llamadas a la API.

Bien, ahora creo que he creado una solución a corto plazo. Sin embargo, no estoy seguro de qué queremos hacer con la recopilación de datos aterradores: las coordenadas tienden a ser bastante precisas (¿deberíamos redondearlas para almacenar en caché las compras?). Definitivamente deberíamos marcar las cosas si son del caché, para dejar en claro que no es 100% exacto.

De todos modos, por ahora, cada vez que el código intente acceder al caché, enviará un mensaje de error.

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

Hola @ joker314 Estoy de acuerdo con tu solución de rechazar con un error. ¿Puedes hacer un PR? Muchas gracias por tomarse el tiempo para investigar esto.

@QuincyLarson, ¿ podrías orientar a quién tiene acceso a este https://fcc-weather-api.glitch.me/ ? Puedo ser delegado si eres el propietario.

@raisedadead Me encantaría, pero miré a mi alrededor y no estoy seguro de si glitch.me realmente admite solicitudes de extracción, a menos que también tenga una copia en GitHub o me falte algo

EDITAR: Por supuesto, el código corregido se puede encontrar en mi remix .

@ joker314 sí, tienes razón, actualizaremos el proyecto desde tu remix. Por favor ignore mi comentario anterior.

Estoy esperando a Quincy la confirmación del acceso a ese proyecto. Muchas gracias por tu ayuda con esto.

@raisedadead - Entonces, ¿cuánto tiempo estará

Entonces, ¿cuánto tiempo estará en vigor esta solución temporal?

Esto no será temporal, con el error se sabrá que el problema se debe a los límites de tarifas.

Este era un contenedor creado sobre la API de OpenWeatherMaps, que no era compatible con https, creo, y por lo tanto entraba en conflicto con codepen.

Si es así, las cosas empeorarán a medida que más campistas creen proyectos meteorológicos. ¿Se puede aumentar el límite de tarifa?

Sí, puede optar por una versión de pago integrando la API directamente en lugar del contenedor de fallas en el desafío.

Ver https://openweathermap.org/price

@raisedadead Parece el código original destinado a que haya un caché. Si este es el caso, y si podemos suavizar los detalles de cómo queremos que se vea exactamente para respetar la privacidad, entonces, ¿podemos solucionar la limitación de la tasa?

Pensándolo bien, quizás sea mejor devolver datos válidos en lugar de un mensaje de error. En su lugar, cambiemos la caché para generar condiciones climáticas aleatorias y establezcamos la ubicación en "API ocupada, inténtelo de nuevo más tarde para obtener resultados reales".

¿Qué piensas sobre esto, @raisedadead?

Como alguien que acaba de completar este proyecto y tuvo el problema de recibir datos meteorológicos japoneses o (la mayoría de las veces) no recibir datos, me gustaría decir que recibir cualquier dato es más útil que ningún dato. Al menos con los datos japoneses pude ver si mi código funcionaba independientemente de que mostrara un clima preciso.

Bueno, en teoría, podríamos enviar datos aleatorios. Pero no queremos recibir quejas sobre datos incorrectos ... lo cual estoy bastante seguro de que será un caso.

De todos modos, si ayuda, tengamos los datos aleatorios.

@QuincyLarson , ¿puede guiarnos con la solicitud anterior ?

Creo que deberíamos enviar datos falsos, pero dejar en claro que son falsos. Haga que el nombre de la ubicación sea "API ocupada, datos falsos" y que el clima, las coordenadas, etc. sean aleatorios en la respuesta. De esta forma, la gente sabe por qué los resultados no son precisos; y, sin embargo, todo seguirá funcionando para los desarrolladores.

Pensamientos

Si envía datos falsos, creo que eso frustraría todo el propósito de proporcionar los datos meteorológicos actuales para una ubicación específica. Me gusta la idea de @ joker314 de averiguar cómo queremos crear el caché e implementarlo.

¿Consideraría fijar las discusiones recientes del foro en la página del proyecto para que los programadores sepan que hay problemas con el proyecto y no pierdan tiempo innecesario tratando de arreglar algo sobre lo que no tienen control?

Por cierto, creo que la URL de la imagen de icon no se devuelve como se describe en https://fcc-weather-api.glitch.me/.
Decía Images links are included in the JSON under weather[0].icon , que no lo es.
Noté que la solución de demostración escribió CSS ​​para dibujar el ícono.

Gracias por informarnos sobre este problema potencial, pero la solicitud de ejemplo y la respuesta incluyen el campo deseado. ¿Qué solicitud en particular hizo que no tuviera este campo?

@ joker314 Gracias por responder.

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}

No noté que el ejemplo funcionaba bien, así que supongo que esto podría deberse a la ubicación o al clima especial.

@ Em-Ant Parece que esto es un problema con la aplicación que se ejecuta en Glitch. ¿Podría echar un vistazo al caché y ver si esto es algo que podamos borrar?

Hice algunas pruebas rápidas, creo que esto está arreglado. Si alguien sigue teniendo problemas, no dude en volver a abrir este problema.

@ moT01 ¿Qué tipo de pruebas hiciste? El problema es que existe un límite de tasa por cuenta de la FCC gratuita que se utiliza para realizar llamadas a la API de OpenWeather. Una vez que se alcanzan esos límites de velocidad, el proxy Glitch devuelve las coordenadas de Japón. La única razón por la que no se ve como un problema en este momento, es que este proyecto ahora es opcional en el plan de estudios, por lo que no tiene tantas visitas como solía haber. Tan pronto como golpee el Glitch 60 veces en un minuto, se devuelve el siguiente 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
}

¿Puede volver a abrir este problema, porque todavía está en mi lista de tareas pendientes de proyectos para solucionar?

Ahh, sí, acabo de hacer un par de llamadas rápidas a la API y pude obtener el clima correcto. Supongo que probablemente debería preguntar un poco más antes de cerrar los números.

Comencé a trabajar en una solución justo al comienzo de Hacktoberfest y luego me involucré mucho en el proceso de control de calidad. El resto es historia. Necesito revisar esto nuevamente, porque ahora tengo una mejor comprensión de Node y Express para poder poner en marcha una solución que funcione.

Hay una caché estática que tiene solo una entrada (la ubicación en Japón).

Podríamos solucionarlo eliminando el limitador de tasa (no sé si es una buena idea, ya que solo tenemos una clave de API allí), o devolver un error de límite de tasa en caso de que excedamos la cuota de solicitudes.

De todos modos, este proyecto de API en glitch es propiedad de @MiloATH , y no podemos editarlo sin 'bifurcarlo', es decir, crear una nueva aplicación con una nueva URL.

He enviado una solicitud para unirme a https://glitch.com/edit/#!/fcc -weather-api usando la cuenta de camperbot a Milo.

¡Parecen buenas ideas! Hay una tercera opción; para arreglar la caché para que los datos se almacenen realmente allí, o para enviar datos aleatorios si se golpea el limitador de velocidad.

Me temo que exceder el límite de velocidad no es una buena idea, ya que la clave de API podría ser revocada en tal circunstancia y es posible que no obtengamos resultados de la API en ningún caso.

@ joker314 Ya me estaba moviendo en la dirección de tu tercera opción.

Pasé una invitación para el proyecto glitch.

El punto final podría ser significativamente mejor. Creo que deberíamos construir un repositorio separado con CI e implementarlo en algo más maduro como Heroku (versión gratuita). Esto nos permitiría trabajar más fácilmente en el proyecto.

Ya no nos desplegaremos en heroku. Usaremos Glitch por ahora. Lo que significa que si hay un proyecto alternativo, nos complace implementarlo en la cuenta de freeCodeCamp en Glitch y reemplazar el desafío existente en el plan de estudios.

@raisedadead @RandellDawson
¡Hola! ¿Alguna actualización sobre esto?
Sería increíble ver algunos diagramas con la arquitectura y el flujo de datos (y eventualmente los nombres de archivo asociados)

@ Hash2C Puede remezclar el proyecto Glitch existente (que se muestra a continuación) para ver y corregir el proyecto.

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

Gracias @RandellDawson , he estado trabajando en ello, espero poder terminar un primer borrador hasta el jueves

@ Hash2C Tómese su tiempo para hacerlo bien. Este error ha estado aquí bastante tiempo.

Gracias @RandellDawson , haré mi mejor
Necesitaré saber un poco más sobre las limitaciones actuales.
Leí anteriormente que tenemos un límite de 60 visitas por minuto, que parece ser el nivel gratuito en los precios de OpenWeather. ¿Hay alguna forma de aumentar este límite? ¿Te gusta crear otras suscripciones a OW? ¿Existen otras "fuentes de la verdad" gratuitas que podríamos utilizar junto con OW?

Editar: Además, ¿qué tipo de demora sería aceptable para entregar? ¿5 minutos? ¿15 minutos? 1h? 3h?

Edit2: parece que la "actualización de datos de la API meteorológica" es "<2 horas" como se muestra en esta tabla
https://openweathermap.org/price
La misma tabla nos dice que la disponibilidad es solo del 95%

¿Hay alguna forma de aumentar este límite? ¿Te gusta crear otras suscripciones a OW?

También pueden tener límites en la dirección IP (no estoy seguro), por lo que crear otras suscripciones no ayudaría.

¿Existen otras "fuentes de la verdad" gratuitas que podríamos utilizar junto con OW?

No es seguro.

Edit2: parece que la "actualización de datos de la API meteorológica" es "<2 horas" como se muestra en esta tabla

Actualmente estoy desarrollando mi propio proyecto meteorológico usando la versión gratuita de OpenWeather y he contemplado simplemente verificar si la solicitud es inferior a 10 minutos desde la última solicitud, luego mostrar los últimos datos devueltos para el mismo lat / lon.

Creo que también podemos actualizar las instrucciones del desafío para que el desarrollador sepa que le enviaremos una respuesta especial si se alcanza un límite, para que pueda informar al usuario de la aplicación que es posible que los datos no estén actualizados. Todavía querríamos devolver los mismos datos que tenemos actualmente (para no romper ningún proyecto antiguo usando la API de la FCC). Solo estaríamos agregando una propiedad adicional a la respuesta. ¿Qué piensas?

Creé este repositorio para que sea más fácil de probar localmente.
https://github.com/Hash2C/fccWeatherApiDraft

Creo que los 3 casos de uso principales (por ahora) ya están cubiertos

• Si las coordenadas no son válidas / inexistentes, envíe un error
  de lo contrario, convierta las coordenadas a un formato conveniente y luego intentamos acceder al caché

• Si las coordenadas solicitadas se almacenan en caché
  
  
  
  • Si la marca de tiempo está dentro del delta aceptable: envíe datos en caché (1)
  
  
  • de lo contrario: configure los datos simulados como datos en caché (en caso de que la llamada a la API de OpenWeather falle posteriormente)
  
  

• else: establezca los datos simulados como algo que decidamos (en caso de que la llamada a la API de OpenWeather falle posteriormente).

• Intentamos llamar a la API de OpenWeather.

• Si obtenemos los datos correctos, envíelos, almacénelos en caché (2)
• De lo contrario, envía los datos de burla (3)

¡Este flujo está enormemente abierto a discusión, por supuesto!

Todavía hay mucho trabajo por hacer, validaciones, cosas asíncronas, casos extremos (pruebas), etc. pero poco a poco llegaremos allí. Comenté mucho el archivo server.js (no te asustes), filtraré gradualmente la mayor parte de esa información y te pediré ayuda aquí para que podamos discutir cada problema.

Solo una idea: ¿podríamos eventualmente tener un servicio de datos que intente minimizar el número de "solicitudes disponibles a la API de OpenWeather (u otras) que no se realizan"? Este servicio alimentaría, digamos, una base de datos MongoDB, esa sería nuestra caché (podríamos usar Memcached pero probablemente sea demasiado, no necesitamos esa velocidad adicional)

Otra idea: ¿Existen estadísticas de uso anteriores de este servicio? Si no es así, tal vez podríamos comenzar a crear uno, tal vez eso podría ser útil, para tratar de optimizar una solución eventualmente posible pero muy subóptima.

Una cosa que seguramente necesitaré un poco de ayuda para entender es que github me advierte sobre estos problemas de seguridad.

(¡por alguna razón, me perdí totalmente tu mensaje!)

También pueden tener límites en la dirección IP (no estoy seguro), por lo que crear otras suscripciones no ayudaría.

Buen punto. ¿Vale la pena probarlo?

¿Existen otras "fuentes de la verdad" gratuitas que podríamos utilizar junto con OW?

No es seguro.

Si se nos permite hacer esto, puede aumentar en gran medida la probabilidad de lograr una solución exitosa.

Actualmente estoy desarrollando mi propio proyecto meteorológico usando la versión gratuita de OpenWeather y he contemplado simplemente verificar si la solicitud es inferior a 10 minutos desde la última solicitud, luego mostrar los últimos datos devueltos para el mismo lat / lon.

Sí, usando datos en caché, ¿verdad? Traje esa pregunta de <2h porque pregunté previamente sobre el retraso aceptable. Cuanto mayor sea el retraso, mejor, por lo que golpeamos más el caché y no tenemos que llamar a la API con tanta frecuencia. Comencé a codificar asumiendo que podemos enviar datos con una antigüedad máxima de 1 hora, solo para comenzar.

Creo que también podemos actualizar las instrucciones del desafío para que el desarrollador sepa que le enviaremos una respuesta especial si se alcanza un límite, para que pueda informar al usuario de la aplicación que es posible que los datos no estén actualizados. Todavía querríamos devolver los mismos datos que tenemos actualmente (para no romper ningún proyecto antiguo usando la API de la FCC). Solo estaríamos agregando una propiedad adicional a la respuesta. ¿Qué piensas?

Estoy totalmente de acuerdo con esta idea de dar la información relevante a los desarrolladores y dejarles elegir, es el camino que yo consideraba el más adecuado también.

¿Existen herramientas estándar para realizar pruebas y realizar solicitudes en los proyectos de FCC?
Para las solicitudes que estoy usando (solo porque decidí probarlo, en lugar de Axios)
www.npmjs.com/package/request
Para las pruebas no tengo mucha experiencia pero estaba pensando en Mocha.
Pero hágame saber qué herramientas se integran mejor con FCC

Una cosa que seguramente necesitaré un poco de ayuda para entender es que github me advierte sobre estos problemas de seguridad.

La solución más simple es simplemente ejecutar npm audit fix y luego confirmar los package.json y package-lock.json actualizados. Los nuevos paquetes no deberían tener cambios importantes con respecto a los anteriores, vulnerables. Sin embargo, eso supone que los autores del paquete no introdujeron accidentalmente un cambio importante, por lo que vale la pena verificar manualmente su aplicación después de que se hayan aplicado las correcciones.

He estado jugando con la API de OpenWeather (en realidad debería haberlo hecho desde el principio).
¿Sabíamos esto? https://openweathermap.org/faq#error401
La parte relevante

Para los desarrolladores de software libre: damos la bienvenida al software gratuito y de código abierto y estamos dispuestos a ayudarlo. Si desea utilizar datos OWM en su aplicación de software gratuita, registre una clave API y presente un ticket que describa su aplicación y la clave API registrada. OWM revisará los límites de acceso de elevación de su solicitud para su clave si se usa en una aplicación de código abierto.

Hola chicos, he estado más limitado de lo esperado.
En mi tiempo libre, he estado estudiando la API de OpenWeather. Desafortunadamente, no está bien documentado.
Creo que se me ocurrió una estrategia factible, usando la opción bbox, pero todavía estoy probando.
Se me ocurrió la idea de crear un documento con toda la información que encontré, las pruebas que estoy haciendo.

@ Hash2C Tómese su tiempo para hacerlo bien. Este error ha estado aquí bastante tiempo.

@RandellDawson
Sabías lo que estabas diciendo: heavy_check_mark:

@ Hash2C ¿Cómo va su solución?

Cerrando este tema ya que la cantidad de usuarios que trabajan en este proyecto en general ha disminuido significativamente ya que ya no es un proyecto requerido para una certificación. Esto ha dado lugar a menos casos en los que se alcanza el límite de frecuencia de la API.