Freecodecamp: FCC Weather API retornando aleatoriamente o clima do Japão

Acho que identifiquei o problema! É simplesmente uma leitura do cache , que contém os dados japoneses.

O cache só é usado se houver mais de sessenta solicitações em sua fila (linha 50). Isso significa que _ às vezes_ ele retornará resultados corretos; mas _ às vezes_ ele retornará esses resultados inesperados.

Como isso pode ser consertado? Temos três opções ...

• Remova o cache
• Torne o cache funcional e realmente use os dados de latitude e longitude ao decidir se deseja usar o cache.
  
  
  
  • Rejeitar a solicitação totalmente se o servidor se sentir sobrecarregado ( recomendado por enquanto )
  
  

Uma vez que este é um pedido de ajuda, adoraria dar uma olhada nisso; no entanto, considerando como isso está interrompendo projetos e como preciso dormir, se alguém quiser consertar isso (a maneira mais fácil é alterar o cache para rejeitar solicitações), faça isso!

Ok, acho que resolvi o problema . Não pude testá-lo, porém, porque não tinha uma chave de API - e há, é claro, o risco de um DOS, já que nunca recorremos ao cache.

Assim, melhorias podem ser feitas. Devemos, talvez, rejeitar solicitações para onde, de outra forma, estaríamos enviando os dados japoneses? Isso é com vocês. Meu conserto é temporário e tentarei melhorar amanhã.

Não acho que posso fazer uma solicitação de pull para a API glitch.me (a menos, é claro, que haja um repositório no GitHub que eu perdi); portanto, alguém com permissão de gravação precisará mesclar minhas alterações após testá-las com uma chave de API funcional.

Certo, estou afk neste momento; mas percebi que a limitação de taxa é necessária. Vou corrigir meu código em breve para que as solicitações sejam negadas se muitas chamadas de API forem feitas.

Ok, agora acho que criei uma solução de curto prazo. Não tenho certeza do que queremos fazer com a coleta de dados assustadores - as coordenadas tendem a ser bastante precisas (devemos arredondá-las para fins de armazenamento em cache?). Definitivamente, devemos marcar as coisas se forem do cache, para deixar claro que não é 100% preciso.

De qualquer forma, por enquanto, sempre que o código tentar acessar o cache, ele enviará uma mensagem de erro.

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

Olá @ joker314 , concordo com sua solução de rejeição com erro. Você pode fazer um PR? Muito obrigado por dedicar seu tempo para investigar isso.

@QuincyLarson você poderia orientar quem tem acesso a este https://fcc-weather-api.glitch.me/ ? Posso ser delegado se você for o proprietário.

@raisedadead Eu adoraria, mas olhei em volta e não tenho certeza se o glitch.me realmente suporta solicitações pull - a menos que você também tenha uma cópia no GitHub ou esteja faltando alguma coisa?

EDIT: Claro, o código corrigido pode ser encontrado no meu remix .

@ joker314 sim você está correto, vamos atualizar o projeto a partir do seu remix. Por favor, ignore meu comentário anterior.

Estou aguardando Quincy a confirmação do acesso a esse projeto. Muito obrigado por sua ajuda com isso.

@raisedadead - Por quanto tempo essa correção temporária ficará em vigor? Qual seria a solução final para isso? É apenas uma questão de limite de taxa? Se for assim, só vai piorar à medida que mais campistas criam projetos climáticos. O limite de taxa pode ser aumentado?

Então, por quanto tempo essa correção temporária estará em vigor?

Não será temporário, com o erro saber-se-á que o problema se deve aos limites de tarifa.

Este era um wrapper criado em cima da API OpenWeatherMaps, que não era compatível com https, eu acho, e, portanto, entrava em conflito com o codepen.

Se for assim, só vai piorar à medida que mais campistas criam projetos climáticos. O limite de taxa pode ser aumentado?

Sim, você pode optar por uma versão paga integrando a API diretamente em vez do invólucro de falha no desafio.

Veja https://openweathermap.org/price

@raisedadead Parece que o código original foi

Pensando bem, talvez seja melhor devolver dados válidos em vez de enviar uma mensagem de erro. Em vez disso, vamos alterar o cache para gerar condições meteorológicas aleatórias e definir o local como "API ocupada, tente novamente mais tarde para obter resultados reais"?

O que você acha disso, @raisedadead?

Como alguém que acabou de concluir este projeto e teve o problema de receber dados meteorológicos japoneses ou (na maioria das vezes) nenhum dado, gostaria de dizer que receber qualquer dado é mais útil do que nenhum dado. Pelo menos com os dados japoneses, pude ver se meu código funcionava independentemente de mostrar o tempo preciso.

Bem, em teoria, poderíamos enviar dados aleatórios. Mas não queremos receber reclamações sobre os dados estarem incorretos ... o que tenho certeza de que será o caso.

De qualquer forma, se ajudar, vamos obter os dados aleatórios.

@QuincyLarson, você pode orientar com o pedido acima ?

Acho que devemos enviar dados falsos, mas deixe claro que são falsos. Faça com que o nome do local seja "API Busy, Fake Data" e o clima, as coordenadas etc. sejam randomizados na resposta. Dessa forma, as pessoas sabem porque os resultados não são precisos; e ainda assim tudo funcionará para desenvolvedores.

Pensamentos?

Se você enviar dados falsos, acredito que isso anularia todo o propósito de fornecer os dados meteorológicos atuais para um local específico. Eu gosto da ideia de @ joker314 sobre descobrir como queremos criar o cache e implementá-lo.

Por favor, você consideraria fixar as discussões recentes do fórum na página do projeto para que os programadores saibam que há problemas com o projeto e não gastem tempo desnecessário tentando consertar algo que eles não têm controle?

BTW, acho que o url da imagem de icon não é retornado conforme descrito em https://fcc-weather-api.glitch.me/.
Dizia Images links are included in the JSON under weather[0].icon , o que não é.
Percebi que a solução demo escreveu css para desenhar o ícone.

Obrigado por nos informar sobre esse possível problema, mas o exemplo de solicitação e resposta inclui o campo desejado. Que solicitação específica você fez que não tinha esse campo?

@ joker314 Obrigado 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}

Não percebi que o exemplo estava funcionando bem, então acho que isso pode ser devido à localização ou ao clima especial.

@ Em-Ant Parece que este é um problema com o aplicativo em execução no Glitch. Você poderia dar uma olhada no cache e ver se isso é algo que podemos limpar?

Fiz alguns testes rápidos, creio que está corrigido. Se alguém ainda estiver tendo problemas, sinta-se à vontade para reabrir este problema.

@ moT01 Que tipo de testes você fez? O problema é que há um limite de taxa para a conta FCC gratuita usada para fazer chamadas para a API OpenWeather. Assim que esses limites de taxa forem atingidos, o proxy do Glitch retorna as coordenadas do Japão. A única razão pela qual não é visto como um problema agora é que este projeto agora é opcional no currículo, então não há tantos acessos a ele como antes. Assim que você acerta o Glitch 60 vezes em um minuto, o seguinte JSON é retornado:

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

Você pode reabrir esse problema, porque ele ainda está na minha lista de tarefas a serem corrigidas?

Ahh, sim - acabei de fazer algumas ligações rápidas para a API e consegui obter o clima correto. Acho que provavelmente devo perguntar um pouco mais antes de encerrar as questões.

Comecei a trabalhar em uma correção logo no início do Hacktoberfest e depois me envolvi muito com o processo de controle de qualidade. O resto é história. Preciso revisitar isso novamente, porque agora tenho um entendimento muito melhor do Node e do Express para poder colocar uma solução em funcionamento.

Existe um cache estático que possui apenas uma entrada (o local no Japão).

Poderíamos consertar removendo o limitador de taxa (não sei se é uma boa ideia, já que temos apenas uma chave de API lá), ou retornar um erro de limite de taxa caso excedamos a cota de solicitações.

De qualquer forma, este projeto de API em falha é propriedade de @MiloATH , e não podemos editá-lo sem 'bifurcá-lo', ou seja, criar um novo aplicativo com uma nova url.

Enviei um pedido de adesão em https://glitch.com/edit/#!/fcc -weather-api usando a conta camperbot para Milo.

Essas parecem boas ideias! Existe uma terceira opção; para consertar o cache para que os dados sejam realmente armazenados nele - ou para enviar dados aleatórios se o limitador de taxa for atingido.

Temo que exceder o limite de taxa não é uma boa ideia, pois a chave da API pode ser revogada em tal circunstância e podemos não obter resultados da API em qualquer caso.

@ joker314 Já estava indo na direção de sua terceira opção.

Passei um convite para o projeto de falha.

O ponto final poderia ser significativamente melhor. Acho que devemos construir um repo separado com CI e implantar em algo mais maduro como Heroku (versão gratuita). Isso nos permitiria trabalhar mais facilmente no projeto.

Não estamos mais implantando no heroku. Estaremos usando o Glitch por enquanto. Ou seja, se houver um projeto alternativo, ficaremos felizes em implantá-lo na conta do freeCodeCamp no Glitch e substituir o desafio existente no Currículo

@raisedadead @RandellDawson
Oi! Alguma atualização sobre isso?
Seria incrível ver alguns diagramas com a arquitetura e o fluxo de dados (e, eventualmente, os nomes de arquivos associados)

@ Hash2C Você pode remixar o projeto Glitch existente (mostrado abaixo) para ver e corrigir o projeto.

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

Obrigado @RandellDawson , estou trabalhando nisso, espero poder terminar um primeiro rascunho até quinta-feira

@ Hash2C Não tenha pressa para fazer a coisa certa. Este bug está aqui há algum tempo.

Obrigado @RandellDawson , farei o meu melhor.
Vou precisar saber um pouco mais sobre as restrições atuais.
Li acima que temos um limite de 60 acessos por minuto, que parece ser o nível gratuito de preços do OpenWeather. Existe uma maneira de aumentar esse limite? Gosta de criar outras assinaturas para OW? Existem outras "fontes de verdade" gratuitas que poderíamos estar usando junto com OW?

Edit: Além disso, que tipo de atraso seria aceitável para entregar? 5min? 15min? 1h? 3h?

Edit2: Parece que o OW "Atualização de dados da API do tempo" é "<2 horas", conforme visto nesta tabela
https://openweathermap.org/price
A mesma tabela nos diz que a disponibilidade é de apenas 95%

Existe uma maneira de aumentar esse limite? Gosta de criar outras assinaturas para OW?

Eles também podem ter limites no endereço IP (não tenho certeza), portanto, criar outras assinaturas não ajudaria.

Existem outras "fontes de verdade" gratuitas que poderíamos estar usando junto com OW?

Não Claro.

Edit2: Parece que o OW "Atualização de dados da API do tempo" é "<2 horas", conforme visto nesta tabela

Atualmente, estou desenvolvendo meu próprio projeto meteorológico usando a versão gratuita do OpenWeather e pensei em apenas verificar se a solicitação está a menos de 10 minutos da última solicitação e, em seguida, mostrar os últimos dados retornados para a mesma latitude / longitude.

Acho que também podemos atualizar as instruções do desafio para que o desenvolvedor saiba que enviaremos uma resposta especial se um limite for atingido, para que eles possam informar ao usuário do aplicativo que os dados podem não estar atualizados. Ainda queremos retornar os mesmos dados que temos atualmente (para não interromper qualquer projeto antigo usando a API FCC). Estaríamos apenas adicionando uma propriedade extra à resposta. O que você acha?

Eu criei este repo para que seja mais fácil testar localmente.
https://github.com/Hash2C/fccWeatherApiDraft

Acredito que os três principais casos de uso (por enquanto) já estão cobertos

• Se as coordenadas forem inválidas / inexistentes, envie um erro
  caso contrário, converta as coordenadas para um formato conveniente e, em seguida, tentamos acessar o cache

• Se as coordenadas solicitadas são armazenadas em cache
  
  
  
  • Se o carimbo de data / hora estiver dentro do delta aceitável: enviar dados em cache (1)
  
  
  • else: definir dados de simulação como dados em cache (no caso de falha na chamada posterior da API OpenWeather)
  
  

• else: definir dados de simulação como algo que decidimos (no caso de falha na chamada da API OpenWeather posterior).

• Tentamos chamar a API OpenWeather.

• Se conseguirmos os dados corretos, envie-os e armazene no cache (2)
• Caso contrário, envie os dados de simulação (3)

Esse fluxo está extremamente aberto para discussão, é claro!

Ainda há muito trabalho a fazer, validações, coisas assíncronas, casos extremos (testes), etc. mas aos poucos chegaremos lá. Comentei muito o arquivo server.js (não se assuste), irei filtrar gradualmente a maior parte dessas informações e pedir ajuda aqui para que possamos discutir cada questão.

Só uma ideia: poderíamos eventualmente ter um serviço de dados, que tenta minimizar o número de "solicitações disponíveis para a API OpenWeather (ou outras) que não são feitas"? Este serviço alimentaria, digamos, um banco de dados MongoDB - que seria nosso cache (poderíamos usar Memcached, mas provavelmente é muito, não precisamos dessa velocidade extra)

Outra ideia: Existem estatísticas de utilização anteriores deste serviço? Se não, talvez pudéssemos começar a criar um, talvez isso pudesse ser útil, para tentar otimizar uma solução eventualmente possível, mas muito abaixo do ideal

Uma coisa que certamente precisarei de ajuda para entender é que o github de Problemas de segurança está me avisando

(por algum motivo, perdi totalmente a sua mensagem!)

Eles também podem ter limites no endereço IP (não tenho certeza), portanto, criar outras assinaturas não ajudaria.

Bom ponto. Vale a pena testar?

Existem outras "fontes de verdade" gratuitas que poderíamos estar usando junto com OW?

Não Claro.

Se tivermos permissão para fazer isso, isso pode aumentar muito a probabilidade de alcançar uma solução bem-sucedida.

Atualmente, estou desenvolvendo meu próprio projeto meteorológico usando a versão gratuita do OpenWeather e pensei em apenas verificar se a solicitação está a menos de 10 minutos da última solicitação e, em seguida, mostrar os últimos dados retornados para a mesma latitude / longitude.

Sim, usando dados em cache, certo? Eu trouxe aquela pergunta de <2h porque perguntei anteriormente sobre o atraso aceitável. Quanto maior o atraso, melhor, então acessamos o cache mais e não precisamos chamar a API com tanta frequência. Codificação iniciada presumindo que possamos enviar dados com no máximo 1 hora, apenas para começar.

Acho que também podemos atualizar as instruções do desafio para que o desenvolvedor saiba que enviaremos uma resposta especial se um limite for atingido, para que eles possam informar ao usuário do aplicativo que os dados podem não estar atualizados. Ainda queremos retornar os mesmos dados que temos atualmente (para não interromper qualquer projeto antigo usando a API FCC). Estaríamos apenas adicionando uma propriedade extra à resposta. O que você acha?

Concordo totalmente com essa ideia de dar as informações relevantes aos desenvolvedores e deixar que eles escolham, é o caminho que eu considerava ser o mais adequado também

Existem ferramentas padrão para teste e para fazer solicitações em projetos FCC?
Para solicitações que estou usando (só porque decidi tentar, em vez de Axios)
www.npmjs.com/package/request
Para testes não tenho muita experiência, mas estava pensando no Mocha.
Mas, por favor, deixe-me saber quais ferramentas se integram melhor com o FCC

Uma coisa que certamente precisarei de ajuda para entender é que o github de Problemas de segurança está me avisando

A solução mais simples é apenas executar npm audit fix e então comprometer package.json e package-lock.json atualizados. Os novos pacotes não devem ter nenhuma alteração significativa em relação aos anteriores e vulneráveis. No entanto, isso pressupõe que os autores do pacote não introduziram acidentalmente uma alteração importante, portanto, vale a pena verificar manualmente seu aplicativo após as correções terem sido aplicadas.

Tenho brincado com a API OpenWeather (na verdade, deveria ter feito isso desde o início).
Nós sabíamos disso? https://openweathermap.org/faq#error401
A parte relevante

Para desenvolvedores FOSS: agradecemos o software de código aberto e gratuito e estamos dispostos a ajudá-lo. Se você deseja usar dados OWM em seu aplicativo de software gratuito, registre uma chave API e preencha um tíquete descrevendo seu aplicativo e a chave API registrada. O OWM analisará seus limites de acesso de elevação de solicitação para sua chave se usada em um aplicativo de código aberto.

Olá pessoal, estou mais restrito do que o esperado.
No meu tempo livre, tenho estudado a API OpenWeather. Infelizmente, não está bem documentado.
Acho que encontrei uma estratégia viável, usando a opção bbox, mas ainda estou testando.
Tive a ideia de criar um documento com todas as informações que encontrei, os testes que estou fazendo.

@ Hash2C Não tenha pressa para fazer a coisa certa. Este bug está aqui há algum tempo.

@RandellDawson
Você sabia o que estava dizendo: heavy_check_mark:

@ Hash2C Como está a sua solução?

Este problema foi encerrado porque o número de usuários trabalhando neste projeto em geral caiu significativamente, pois não é mais um projeto obrigatório para uma certificação. Isso levou a menos casos em que o limite de taxa para a API foi atingido.