Как избежать потенциальных проблем при повторной обработке всех постов?

Привет!

Повторная обработка всех сообщений иногда рекомендуется по разным причинам.

Опираясь на свой собственный опыт повторной обработки, который вызвал проблемы, и видя/предвидя другие потенциальные проблемы, я хотел бы узнать, как их можно избежать.

  • Если я повторно обработаю свои 2 миллиона сообщений, это вызовет слишком много запросов к YouTube, и мой IP-адрес будет заблокирован, что помешает Discourse генерировать предпросмотры.

  • Если исходные URL-адреса onebox-ов (с заголовками, миниатюрами и выдержками, скопированными в базу данных Discourse — поле cooked) станут нерабочими или будут перенаправлены, кажется, что onebox-ы сломаются, и мы потеряем эту информацию.

  • У меня есть старые onebox-ы Facebook и Instagram, которые отображаются корректно. В настоящее время они не отображаются так (они показываются во фрейме iframe, см. этот коммит).
    Дополнительная информация: Instagram embedding features and layout (обратите внимание, что макет немного изменился с тех пор, и теперь фреймы iframe обрезают контент) и Facebook oneboxes not working on my forums (кажется, даже Discord не может иметь «доверенный» IP…? Это публичная ссылка).

  • Я решил отказаться от поддержки Facebook (и, следовательно, Instagram, насколько мне известно) на своих форумах по нескольким причинам. Если я повторно обработаю все свои сообщения, я предполагаю, что каждая ссылка, которая ранее корректно отображалась как onebox, сломается. Правильно ли я понимаю?

Чтобы обойти некоторые из этих проблем, может помочь "Onebox Assistant", crawl for those previews reliably!, но не во всех случаях. Например, это не поможет мне с предпросмотрами Facebook.


Что можно сделать, чтобы сохранить существующую информацию onebox-ов во время повторной обработки?

Мне кажется, нам нужно улучшить функцию повторной обработки, чтобы она была более осторожной:

  • ограничение скорости для выбранных сайтов или, возможно, для всех сайтов
  • наследование оригинального onebox, если повторный запрос не удался по какой-либо причине

Другими словами, я думаю, нам нужна безопасная повторная обработка, по крайней мере, как выбираемая опция.

(Существуют сообщества Discourse, которые ценят актуальные сообщения 404 или не придают значения старым сообщениям, но есть также сообщества, которые очень хотят сохранить старые темы в неизменном виде.)

Может быть, переформулировать это и переклассифицировать как запрос на новую функцию?

Есть ли вообще какой-либо смысл в автоматическом повторном получении содержимого твита? Меня бы устроило, если бы rebake пропускал повторное получение одноблочного контента, если не установлен соответствующий флажок.

Хорошая мысль — это более надёжно и менее вероятно приведёт к проблемам с ограничением частоты запросов. Не трогайте все oneboxes, если не указано иное.

Спасибо за пост. Это может повлиять на то, над чем я работаю. Есть ли у вас представление, сколько запросов нужно для достижения лимита?

Судя по документации YouTube API, они разрешают до 10 000 GET-запросов за 24 часа, но это для запросов, сделанных с использованием API-ключа: YouTube Data API Overview  |  Google for Developers. Мне неясно, как ограничиваются запросы без аутентификации для загрузки превью-изображений видео.

Я не думаю, что для воспроизведения видео через iframe применяется какой-либо лимит, но было бы хорошо это подтвердить: YouTube Player API Reference for iframe Embeds  |  YouTube IFrame Player API  |  Google for Developers.

Я не знаю.

Я решил проблему, используя Onebox Assistant без какого-либо API. Просто включил плагин. Не знаю, как именно это решило мою проблему. Также не знаю, будет ли это работать сейчас.