Freecodecamp: FCC Weather API가 무작위로 일본 날씨를 반환

문제를 확인한 것 같습니다! 일본어 데이터를 포함하는 캐시에서 읽는 것 입니다.

캐시는 대기열에 60 개 이상의 요청이있는 경우에만 사용됩니다 (50 행). 즉, _ 가끔 _ 올바른 결과를 반환합니다. 그러나 _ 가끔 _ 예상치 못한 결과를 반환합니다.

이 문제를 어떻게 해결할 수 있습니까? 세 가지 옵션이 있습니다 ...

• 캐시 제거
• 캐시가 작동하도록 만들고 캐시 사용 여부를 결정할 때 실제로 위도 및 경도 데이터를 사용합니다.
  
  
  
  • 서버에 과부하가 걸린다고 느끼면 요청을 완전히 거부합니다 ( 현재 권장 ).
  
  

이것은 도움이 필요하기 때문에 이것을보고 싶습니다. 그러나 이것이 프로젝트를 방해하는 방법과 수면이 필요한 방법을 고려할 때 누군가이 문제를 해결하고 싶다면 (가장 쉬운 방법은 요청을 거부하도록 캐시를 변경하는 것입니다) 그렇게하십시오!

알겠습니다. 문제를 해결 한 것 같습니다 . 하지만 API 키가 없었기 때문에 테스트 할 수 없었습니다. 물론 캐싱에 의존하지 않는 DOS의 위험도 있습니다.

따라서 개선이 이루어질 수 있습니다. 아마도 일본 데이터를 보낼 곳에서 요청을 거부해야할까요? 이것은 모두에게 달려 있습니다. 임시로 수정하고 내일 더 나아지도록 노력하겠습니다.

glitch.me API에 풀 리퀘스트를 할 수 없다고 생각합니다 (물론 제가 놓친 GitHub에 리포지토리가있는 경우는 제외). 따라서 쓰기 권한이있는 사람은 작동하는 API 키로 테스트 한 후 변경 사항을 병합해야합니다.

맞습니다, 저는 지금 afk입니다. 하지만 속도 제한이 필요하다는 것을 깨달았습니다. API 호출이 너무 많으면 요청이 거부되도록 코드를 곧 수정하겠습니다.

좋아요, 이제 단기적으로 해결책을 만든 것 같습니다. 하지만 무서운 데이터 수집에 대해 우리가 무엇을하고 싶은지 잘 모르겠습니다. 좌표는 매우 정확한 경향이 있습니다. 그것이 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 오류로 거부하는 귀하의 솔루션에 동의합니다. 홍보 해주시 겠어요? 시간을내어 조사해 주셔서 감사합니다.

@QuincyLarson 이 https://fcc-weather-api.glitch.me/에 액세스 할 수있는 사람을 안내 할 수 있습니까? 당신이 소유자라면 위임 할 수 있습니다.

@raisedadead 하고 싶지만 주위를 둘러 봤는데 glitch.me가 실제로 pull 요청을 지원하는지 확실하지 않습니다.

편집 : 물론 수정 된 코드는 내 리믹스 에서 찾을 수 있습니다.

@ joker314 맞습니다 . 리믹스에서 프로젝트를 업데이트합니다. 이전 의견을 무시하십시오.

해당 프로젝트에 대한 액세스 확인을 Quincy에서 기다리고 있습니다. 도움을 주셔서 감사합니다.

@raisedadead- 이 임시 수정은 얼마나 오래 적용 될까요? 이에 대한 궁극적 인 솔루션은 어떤 모습일까요? 이것은 속도 제한 문제입니까? 만약 그렇다면, 더 많은 캠핑 객이 날씨 프로젝트를 만들면서 상황은 더욱 악화 될 것입니다. 속도 제한을 늘릴 수 있습니까?

그렇다면이 임시 수정은 얼마나 오래 적용 될까요?

이것은 일시적인 것이 아니며 오류가 발생하면 속도 제한으로 인한 문제라는 것을 알 수 있습니다.

이것은 https를 지원하지 않는 OpenWeatherMaps API 위에 생성 된 래퍼 였기 때문에 코드 펜과 충돌했습니다.

만약 그렇다면, 더 많은 캠핑 객이 날씨 프로젝트를 만들면서 상황은 더욱 악화 될 것입니다. 속도 제한을 늘릴 수 있습니까?

예, 챌린지에서 글리치 래퍼 대신 API를 직접 통합하여 유료 버전을 선택할 수 있습니다.

https://openweathermap.org/price 참조

@raisedadead 캐시가있는 원래 코드처럼 보입니다. 이것이 사실이고 프라이버시를 존중하기 위해 이것이 정확히 어떻게 보이길 원하는지에 대한 세부 사항을 부드럽게 할 수 있다면 속도 제한을 해결할 수 있기를 바랍니다.

다시 생각하면 오류 메시지 대신 유효한 데이터를 다시 제공하는 것이 가장 좋습니다. 대신 임의의 기상 조건을 생성하도록 캐시를 변경하고 위치를 "API 사용 중입니다. 나중에 실제 결과를 위해 다시 시도하십시오"로 설정 하시겠습니까?

@raisedadead, 이것에 대한 당신의 생각은 어떻습니까?

이 프로젝트를 막 완료하고 일본 날씨 데이터를 받거나 (대부분) 데이터가없는 문제가있는 사람으로서 데이터를받지 않는 것보다 데이터를받는 것이 더 유용하다고 말하고 싶습니다. 적어도 일본 데이터를 사용하면 정확한 날씨를 보여 주더라도 내 코드가 작동하는지 확인할 수있었습니다.

이론적으로는 임의의 데이터를 보낼 수 있습니다. 그러나 우리는 데이터가 정확하지 않다는 불만을 받고 싶지 않습니다.

어쨌든 도움이된다면 임의의 데이터를 가질 수 있습니다.

@QuincyLarson 위의 요청으로 안내해 주시겠습니까?

가짜 데이터를 보내야한다고 생각하지만 그것이 가짜라는 것을 분명히합니다. 위치 이름을 "API Busy, Fake Data"로 지정하고 응답에서 날씨, 좌표 등을 무작위로 지정합니다. 이렇게하면 사람들은 결과가 정확하지 않은 이유를 알 수 있습니다. 그러나 모든 것이 여전히 개발자를 위해 작동합니다.

생각?

가짜 데이터를 보내면 특정 위치에 대한 현재 날씨 데이터를 제공하는 모든 목적을 무너 뜨릴 수 있다고 생각합니다. 나는 캐시를 생성하고 구현하는 방법을 파악하는 것에 대한 @ joker314 의 아이디어를 좋아합니다.

코더가 프로젝트에 문제가 있음을 알고 제어 할 수없는 문제를 해결하는 데 불필요한 시간을 소비하지 않도록 프로젝트 페이지에 최근 포럼 토론을 고정하는 것을 고려해 주시겠습니까?

BTW, https://fcc-weather-api.glitch.me/에 설명 된대로 icon 의 이미지 URL이 반환되지 않는다고 생각합니다 .
Images links are included in the JSON under weather[0].icon 라고
데모 솔루션이 아이콘을 그리기 위해 CSS를 작성했음을 알았습니다.

이 잠재적 인 문제에 대해 알려 주셔서 감사합니다. 요청 및 응답 예제에는 원하는 필드가 포함되어 있습니다. 이 필드가없는 특별한 요청은 무엇입니까?

@ joker314 답장을위한 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 계정 당 속도 제한이 있다는 것입니다. 이러한 속도 제한에 도달하면 Glitch 프록시가 일본 좌표를 반환합니다. 지금 당장 문제로 간주되지 않는 유일한 이유는이 프로젝트가 이제 커리큘럼에서 선택 사항이므로 예전만큼 히트가 많지 않기 때문입니다. 1 분에 글리치를 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
}

수정해야 할 프로젝트의 할 일 목록에 아직 남아 있으므로이 문제를 다시 열 수 있습니까?

Ahh, yea-방금 api를 몇 번 빠르게 호출했고 정확한 날씨를 얻을 수있었습니다. 문제를 해결하기 전에 조금 더 문의해야한다고 생각합니다.

저는 Hacktoberfest를 시작할 때 바로 수정 작업을 시작했고 QA 프로세스에 크게 참여했습니다. 나머지는 역사이다. 이제 작업 솔루션을 얻을 수 있도록 Node와 Express에 대해 훨씬 더 잘 이해했기 때문에 이것을 다시 검토해야합니다.

항목이 하나만있는 정적 캐시가 있습니다 (일본의 위치).

비율 제한기를 제거하여 수정하거나 (좋은 생각인지 모르겠습니다. API 키가 하나뿐이므로) 요청 할당량을 초과하는 경우 비율 제한 오류를 반환합니다.

어쨌든 글리치에 대한이 API 프로젝트는 @MiloATH 소유

Camperbot 계정을 사용하여 https://glitch.com/edit/#!/fcc -weather-api에서 Milo에 가입 요청을 보냈습니다.

좋은 아이디어 같네요! 세 번째 옵션이 있습니다. 데이터가 실제로 거기에 저장되도록 캐시를 수정하거나 속도 제한기에 도달하면 임의의 데이터를 전송합니다.

속도 제한을 초과하는 것은 이러한 상황에서 API 키가 취소 될 수 있으며 어떤 경우에도 API에서 결과를 얻지 못할 수 있으므로 좋은 생각이 아닐까 두렵습니다.

@ joker314 이미 세 번째 옵션의 방향으로 움직이고있었습니다.

글리치 프로젝트에 초대를 전달했습니다.

엔드 포인트는 훨씬 더 좋을 수 있습니다. CI로 별도의 리포지토리를 구축하고 Heroku (무료 버전)와 같은 더 성숙한 것에 배포해야한다고 생각합니다. 이것은 우리가 프로젝트에서 더 쉽게 작업 할 수있게합니다.

우리는 더 이상 heroku에 배포하지 않습니다. 지금은 Glitch를 사용할 것입니다. 대체 프로젝트가 있으면 Glitch의 freeCodeCamp 계정으로 배포하고 커리큘럼의 기존 과제를 대체하게되어 기쁩니다.

트윗 담아 가기
안녕하세요! 이것에 대한 업데이트가 있습니까?
아키텍처와 데이터 흐름 (그리고 결국 관련 파일 이름)이 포함 된 다이어그램을 보는 것은 멋질 것입니다.

@ Hash2C 기존 Glitch 프로젝트 (아래 참조)를 리믹스하여 프로젝트를보고 수정할 수 있습니다.

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

감사합니다 @RandellDawson , 작업 중입니다. 목요일까지 첫 번째 초안을 마칠 수 있기를 바랍니다.

@ Hash2C 시간을

@RandellDawson 감사합니다. 최선을 다하겠습니다.
현재의 제약에 대해 조금 더 알아야합니다.
위에서 우리는 분당 60 개의 히트 제한이 있다는 것을 읽었으며, 이는 OpenWeather 가격 책정의 무료 계층 인 것 같습니다. 이 한도를 늘리는 방법이 있습니까? OW에 대한 다른 구독을 만드는 것과 같은가요? OW와 함께 사용할 수있는 다른 무료 "진실 소스"가 있습니까?

편집 : 또한 어떤 종류의 지연이 허용됩니까? 5 분? 15 분? 1 시간? 3 시간?

Edit2 :이 표에서 볼 수 있듯이 OW "Weather API 데이터 업데이트"가 "<2 시간"인 것 같습니다.
https://openweathermap.org/price
동일한 표에서 가용성이 95 %에 불과 함을 알 수 있습니다.

이 한도를 늘리는 방법이 있습니까? OW에 대한 다른 구독을 만드는 것과 같은가요?

또한 IP 주소에 제한이있을 수 있으므로 (확실하지 않음) 다른 구독을 만드는 것은 도움이되지 않습니다.

OW와 함께 사용할 수있는 다른 무료 "진실 소스"가 있습니까?

확실하지 않아.

Edit2 :이 표에서 볼 수 있듯이 OW "Weather API 데이터 업데이트"가 "<2 시간"인 것 같습니다.

저는 현재 OpenWeather의 무료 버전을 사용하여 자체 날씨 프로젝트를 개발 중이며 요청이 마지막 요청에서 10 분 미만인지 확인한 다음 동일한 위도 / 경도에 대해 마지막으로 반환 된 데이터를 표시하는 것을 고려했습니다.

개발자에게 제한에 도달하면 특별 응답을 보내 겠다는 사실을 알리기 위해 챌린지 지침을 업데이트하여 앱 사용자에게 데이터가 최신 상태가 아닐 수 있음을 알릴 수도 있다고 생각합니다. FCC API를 사용하여 이전 프로젝트를 중단하지 않도록 현재와 동일한 데이터를 반환하고 싶습니다. 응답에 추가 속성을 추가하는 것뿐입니다. 어떻게 생각해?

이 저장소를 만들었으므로 로컬에서 테스트하기가 더 쉽습니다.
https://github.com/Hash2C/fccWeatherApiDraft

3 가지 주요 사용 사례 (당분간)가 이미 다루어 졌다고 생각합니다.

• 좌표가 유효하지 않거나 존재하지 않는 경우 오류를 보냅니다.
  그렇지 않으면 좌표를 편리한 형식으로 변환 한 다음 캐시에 도달하려고합니다.

• 요청 된 좌표가 캐시 된 경우
  
  
  
  • 타임 스탬프가 허용 가능한 델타 내에있는 경우 : 캐시 된 데이터 전송 (1)
  
  
  • else : 모의 데이터를 캐시 된 데이터로 설정 (나중에 OpenWeather API 호출이 실패 할 경우)
  
  

• 그렇지 않으면 : 모의 데이터를 우리가 결정한 것으로 설정합니다 (나중에 OpenWeather api 호출이 실패 할 경우).

• OpenWeather API를 호출하려고합니다.

• 올바른 데이터를 얻으면 전송하고 캐시에 저장하십시오. (2)
• 그렇지 않으면 모의 데이터를 보냅니다. (3)

이 흐름은 물론 토론의 여지가 많습니다!

아직해야 할 일, 유효성 검사, 비동기 작업, 엣지 케이스 (테스트) 등이 많이 남아 있지만 점차적으로 도달 할 것입니다. server.js 파일에 대해 많이 댓글을 달았습니다 (두려워하지 마세요). 점차적으로 대부분의 정보를 필터링하고 여기에서 도움을 요청하여 각 문제에 대해 논의 할 것입니다.

단지 아이디어입니다. 결국 "수행되지 않은 OpenWeather API (또는 기타)에 대한 사용 가능한 요청"의 수를 최소화하려는 데이터 서비스를 가질 수 있습니까? 이 서비스는 예를 들어 MongoDB 데이터베이스를 공급할 것입니다. 캐시가 될 것입니다 (Memcached를 사용할 수 있지만 너무 많을 수 있습니다. 추가 속도가 필요하지 않습니다).

기타 아이디어 :이 서비스의 과거 사용 통계가 있습니까? 그렇지 않다면, 아마도 우리는 하나를 만들기 시작할 수있을 것입니다. 아마도 그것은 결국 가능하지만 매우 차선적인 솔루션을 최적화하기 위해 유용 할 수 있습니다.

이해하는 데 도움이 필요한 한 가지는 github가 경고하는 보안 문제입니다.

(어떤 이유로 나는 당신의 메시지를 완전히 놓쳤습니다!)

또한 IP 주소에 제한이있을 수 있으므로 (확실하지 않음) 다른 구독을 만드는 것은 도움이되지 않습니다.

좋은 지적. 테스트 할 가치가 있습니까?

OW와 함께 사용할 수있는 다른 무료 "진실 소스"가 있습니까?

확실하지 않아.

이렇게 할 수 있다면 성공적인 솔루션을 얻을 확률이 크게 높아질 수 있습니다.

저는 현재 OpenWeather의 무료 버전을 사용하여 자체 날씨 프로젝트를 개발 중이며 요청이 마지막 요청에서 10 분 미만인지 확인한 다음 동일한 위도 / 경도에 대해 마지막으로 반환 된 데이터를 표시하는 것을 고려했습니다.

예, 캐시 된 데이터를 사용하고 있습니까? 이전에 허용 가능한 지연에 대해 질문했기 때문에 2 시간 미만의 질문을 가져 왔습니다. 지연 시간이 길수록 더 좋기 때문에 캐시에 더 많이 접근하고 API를 자주 호출 할 필요가 없습니다. 시작하기 위해 최대 1 시간 전에 데이터를 보낼 수 있다고 가정하고 코딩을 시작했습니다.

개발자에게 제한에 도달하면 특별 응답을 보내 겠다는 사실을 알리기 위해 챌린지 지침을 업데이트하여 앱 사용자에게 데이터가 최신 상태가 아닐 수 있음을 알릴 수도 있다고 생각합니다. FCC API를 사용하여 이전 프로젝트를 중단하지 않도록 현재와 동일한 데이터를 반환하고 싶습니다. 응답에 추가 속성을 추가하는 것뿐입니다. 어떻게 생각해?

나는 개발자에게 관련 정보를 제공하고 개발자가 선택할 수 있도록하는이 아이디어에 전적으로 동의합니다. 이것이 제가 가장 적절하다고 생각했던 경로이기도합니다.

FCC 프로젝트에서 테스트 및 요청을위한 표준 도구가 있습니까?
사용중인 요청의 경우 (Axios 대신 사용해보기로 결정했기 때문에)
www.npmjs.com/package/request
테스트를 위해 경험이 많지는 않지만 모카에 대해 생각하고있었습니다.
하지만 어떤 도구가 FCC와 더 잘 통합되는지 알려주세요

이해하는 데 도움이 필요한 한 가지는 github가 경고하는 보안 문제입니다.

가장 간단한 해결책은 npm audit fix 을 실행 한 다음 업데이트 된 package.json 및 package-lock.json 를 커밋하는 것입니다. 새 패키지는 이전의 취약한 패키지에서 변경된 사항이 없어야합니다. 그러나 패키지 작성자가 실수로 주요 변경 사항을 도입하지 않았다고 가정하므로 수정 사항이 적용된 후 앱을 수동으로 확인하는 것이 좋습니다.

저는 OpenWeather API를 가지고 놀았습니다 (실제로 처음부터이 작업을 수행 했어야했습니다).
우리가 알고 있었나요? https://openweathermap.org/faq#error401
관련 부분

FOSS 개발자 : 무료 및 오픈 소스 소프트웨어를 환영하며 기꺼이 도와 드리겠습니다. 무료 소프트웨어 애플리케이션에서 OWM 데이터를 사용하려면 API 키를 등록하고 등록 된 애플리케이션 및 API 키를 설명하는 티켓을 제출하십시오. OWM은 오픈 소스 애플리케이션에서 사용되는 경우 키에 대한 요청 리프트 액세스 제한을 검토합니다.

안녕하세요 여러분, 저는 예상보다 더 많은 제약을 받았습니다.
여가 시간에는 OpenWeather API를 공부하고 있습니다. 불행히도 잘 문서화되어 있지 않습니다.
bbox 옵션을 사용하여 실행 가능한 전략을 생각 해낸 것 같지만 아직 테스트 중입니다.
나는 내가 만난 모든 정보, 내가 수행하는 테스트로 문서를 만드는 아이디어를 생각해 냈습니다.

@ Hash2C 시간을

안녕하세요.
당신은 당신이 무슨 말을하는지 알고있었습니다 : heavy_check_mark :

@ Hash2C 솔루션은 어떻게 진행되고 있습니까?

더 이상 인증에 필요한 프로젝트가 아니기 때문에 일반적으로이 프로젝트에서 작업하는 사용자 수가 크게 감소하여이 문제를 종결했습니다. 이로 인해 API에 대한 비율 제한에 도달하는 인스턴스 수가 줄어 들었습니다.