Как мне обеспечить предварительный просмотр изображений сайтов при использовании Google Web Search API?

Question

Я использую API пользовательского поиска Google для динамического предоставления результатов веб-поиска. Я очень интенсивно искал документы API и не смог найти ничего, что бы указывало на то, что оно предоставляет вам доступ к предварительным просмотрам изображений на сайте Google, которые хранятся в кодировке base64.

Я хочу предоставить возможность предварительного просмотра изображений для сайтов по каждому URL, который возвращает API веб-поиска Google. Имейте в виду, что я не хочу, чтобы эти изображения были миниатюрами, а скорее большими изображениями. Мой вопрос заключается в том, как лучше всего это сделать с точки зрения как эффективности, так и стоимости, как в краткосрочной, так и в долгосрочной перспективе.

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

Другим вариантом будет динамическое получение изображений сразу после того, как API Google вернет результаты поиска. Однако, где / как я получаю изображения, другой вопрос.

Был бы недорогой способ, чтобы я сам генерировал изображения? Или лучшим решением было бы использовать какой-нибудь сервис миниатюр сайтов, который делает это для меня? Будет ли это достаточно быстро? Это будет слишком дорого? Будет ли служба предоставить изображение в правильном размере для меня? Если нет, то как я могу изменить размер изображения?

Я бы очень признателен за исчерпывающие ответы на любые примеры кода в ruby ​​с использованием rails.

Answer 1

Итак, как вы указали в своем вопросе, я вижу два подхода к вашей проблеме:

1. Использование внешнего сервиса для рендеринга и размещения изображений.
2. Рендеринг и размещение изображений самостоятельно.

Я не специалист в этой области, но мой Google до сих пор имеет только возвращенные сервисы, которые позволяют генерировать миниатюры, а не полноразмерные скриншоты (как несколько упомянутых выше). здесь ).Если есть хостинговые сервисы, которые сделают это для вас, я не смог бы их легко найти.

Итак, уходит # 2.Для этого мой первый инстинкт был искать библиотеку ruby, которая могла бы генерировать изображение с веб-страницы, что быстро привело меня к IMGKit (могут быть и другие, но этот выглядел чистым и простым).С помощью этой библиотеки вы можете легко передать URL-адрес, и она будет использовать движок webkit для создания скриншота страницы для вас.Оттуда я бы сохранил его там, где хранятся ваши активы (например, Amazon S3 ), используя драгоценный камень вложения, например Скрепка или CarrierWave ( railscast).Сохраните вложение с полем, в котором записан исходный URL-адрес, который вы передали в IMGKit из WSAPI (API веб-поиска), чтобы можно было сравнивать его с последующими поисками и использовать кэшированную версию вместо повторной визуализации предварительного просмотра.Вы также можете использовать поле created_at для вашей модели вложения, чтобы добавить некоторую логику типа «если старше x дней, обновите изображение».Наконец, я бы поместил все это в фоновое задание, используя что-то вроде resque ( railscast ), чтобы пользователь не блокировался при ожидании рендеринга скриншотов.Передайте массив возвращенных URL-адресов из WSAPI фоновым работникам в режиме resque, которые будут генерировать изображения с помощью IMGKit - сохраняя их в S3 через paperclip / carrierwave, в основном.Все эти проекты хорошо документированы, и Railscasts проведет вас через основы драгоценных камней resque и carrierwave.

Я не сократил числа, но вы можете не принимать изображения самостоятельно на S3 против любого другого внешнего провайдера создания веб-миниатюр.Конечно, выполнение этого самостоятельно дает вам полный контроль над тем, как выглядит изображение (качество, формат и т. Д.), В то время как большинство служб, с которыми я сталкивался, предлагают лишь небольшую миниатюру, поэтому есть что сказать по этому поводу.Если вы не кэшируете изображения из предыдущих поисков, ваши затраты снижаются еще больше, поскольку вы всегда будете рендерить изображения на лету.Однако я подозреваю, что это не очень хорошо масштабируется, так как вы можете в конечном итоге платить гораздо больше за мощность сервера (для IMGKit и обработки изображений) и пропускную способность (за внешние запросы на выбор исходного HTML-кода для IMGKit).Я бы обязательно включил в ваш проект некоторые метрики , чтобы прикрепить некоторые точные цифры к типу запросов, с которыми вы имеете дело, чтобы помочь определить, каковы будут последующие затраты.

AnywhoЭто был бы мой подход высокого уровня.Надеюсь, это поможет некоторым.

Answer 2

Снимки экрана с веб-страниц очень надежны. Основная проблема заключается в том, что все текущие решения (khtml2png, CutyCapt, Phantom.js и т. Д.) Основаны на QT, который обеспечивает доступ к встроенной библиотеке Webkit. Однако эта сборка webkit довольно старая и в HTML5 и CSS3 большинство эффектов либо не отображаются, либо отображаются неправильно.

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

Версия TLDR; теперь он использует URL2PNG , чтобы сделать все свои миниатюры и снимки экрана в полном размере. Это не бесплатно, но он говорит, что это делает работу за него. Если вы не хотите их использовать, у них есть список их конкурентов здесь .