모든 게시물을 다시 베이킹할 때 잠재적인 문제를 피하는 방법?

제품 지원
1

안녕하세요!

여러 가지 이유로 인해 모든 게시물을 다시 생성(Rebake)하는 것이 권장되는 조치인 경우가 있습니다.

본인도 다시 생성 과정에서 문제가 발생한 경험을 했으며, 다른 잠재적 문제들도 보고/예상했기에 이러한 문제들을 어떻게 피할 수 있는지 알고 싶습니다.

이러한 문제 중 일부를 우회하기 위해 "Onebox Assistant", crawl for those previews reliably! 가 도움이 될 수 있지만, 모든 경우에 해당하지는 않습니다. 예를 들어 Facebook 미리보기에는 도움이 되지 않았습니다.

다시 생성(Rebake) 시 기존 원박스 정보를 보존하기 위해 무엇을 할 수 있습니까?

2

재베이킹 기능에 더 신중할 수 있도록 개선이 필요하다고 생각합니다.

  • 선택된 사이트 또는 모든 사이트에 대해 속도 제한(rate limit) 적용
  • 어떤 이유로든 재검색(refetch)이 실패하면 원래의 원박스를 상속

즉, 선택 가능한 옵션으로라도 최소한 파괴적이지 않은(non-damaging) 재베이킹이 필요하다고 생각합니다.

(최신화된 404 상태를 중시하거나, 오래된 게시물 자체를 전혀 중요하게 여기지 않는 Discourse 커뮤니티가 있을 수 있지만, 오래된 스레드를 온전히 보존하기를 매우 원하는 커뮤니티도 있을 것입니다.)

3

기능 요청으로 다시 작성하고 재분류할 수 있을까요?

4

트윗의 내용을 자동으로 다시 가져오는 데 정말로 어떤 가치가 있을까요? 박스가 체크되지 않는 한, 리베이크가 원박스된 내용을 다시 가져오는 것을 건너뛰는 방식으로 진행되어도 괜찮습니다.

5

좋은 생각이에요. 더 견고하고, 속도 제한 문제로 인한 오류 발생 가능성도 낮아지니까요. 별도로 지정되지 않는 한 모든 원박스(onebox)는 그대로 두세요.

6

해당 내용을 게시해 주셔서 감사합니다. 제가 작업 중인 프로젝트에 영향을 미칠 수 있습니다. 제한이 발동되는 요청 횟수에 대해 어떤 아이디어가 있으신가요?

YouTube API 문서를 살펴보니, API 키를 사용하여 요청을 보낼 경우 24시간당 최대 10,000회의 GET 요청이 허용되는 것으로 보입니다: YouTube Data API Overview  |  Google for Developers. 그러나 인증되지 않은 API 요청을 통해 비디오 미리보기 이미지를 가져오는 경우의 속도 제한(rate limit) 방식은 명확하지 않습니다.

iframe을 통해 _재생_되는 비디오에는 속도 제한이 적용되지 않는다고 생각하지만, 이를 확인하는 것이 좋습니다: YouTube Player API Reference for iframe Embeds  |  YouTube IFrame Player API  |  Google for Developers.

7

모르겠습니다.

API를 사용하지 않고 Onebox Assistant만 활성화하여 문제를 해결했습니다. 어떻게 문제가 해결되었는지 정확히 알 수 없으며, 현재에도 작동할지 역시 알 수 없습니다.