Comments 28
Необходимость подобных сервисов напрямую зависит от их доступности. Лично для меня сервис будет представлять интерес только в случае его бесплатности (во всех отношениях) и постоянной доступности. Многим еще захочется создать свою локальную копию. Идея вполне годная и нужная.
Никто не ведет речь о какой-либо оплате. В отношении доступности — согласен, надо предусмотреть возможные варианты балансировки, отказоустойчивости.
Никто не ведет речь о какой-либо оплате
Ну это пока не ведет ) Было бы крайне печально перевести крупный проект на это решение, а затем узнать что оно стало платным. А монитизировать его понадобится, ибо без этого на постоянную доступность можно не расчитывать.
Соглашусь. В большинстве случаев подобные сервисы работают по схеме «Больше обращений — больше стоимость». Как пример могу привести prerender.io. Но тут тоже есть определенный смысл — больше обращений означает востребованность исходного ресурса. Большая востребованность означает возможность получения выгоды (если это не благотворительная деятельность), что допускает возможные расходы, пусть и минимальные, на одну из компонент своей инфраструктуры.
Вот аналогичный сервис: uploadcare.com
Но у вас проще использовать, т.к. не требуется регистрироваться, заливать картинку, а потом ее тягать, достаточно просто подставить в УРЛ. Но в этом направлении, кстати, можно подумать с точки зрения монетизации: для использования так, как есть, оставить сервис бесплатным. Но предусмотреть и регистрацию юзеров, введя дополнительные фишки для них, и это уже сделать платным.
Как вариант: при бесплатном использовании хранить изображения в течение ограниченного времени (напр., месяц). Даже это будет большой плюс для тех, кто не хочет заморачиваться с ресайзом — прогнал картинку через ваш сервис при загрузке и сохранил у себя. А для платных хранить уже «вечно». В любом случае, если у сервиса будет расти популярность, то думать о монетизации придется, т.к. рано или поздно громадное хранилище картинок начнет требовать ощутимых ресурсов.
Но у вас проще использовать, т.к. не требуется регистрироваться, заливать картинку, а потом ее тягать, достаточно просто подставить в УРЛ. Но в этом направлении, кстати, можно подумать с точки зрения монетизации: для использования так, как есть, оставить сервис бесплатным. Но предусмотреть и регистрацию юзеров, введя дополнительные фишки для них, и это уже сделать платным.
Как вариант: при бесплатном использовании хранить изображения в течение ограниченного времени (напр., месяц). Даже это будет большой плюс для тех, кто не хочет заморачиваться с ресайзом — прогнал картинку через ваш сервис при загрузке и сохранил у себя. А для платных хранить уже «вечно». В любом случае, если у сервиса будет расти популярность, то думать о монетизации придется, т.к. рано или поздно громадное хранилище картинок начнет требовать ощутимых ресурсов.
Да, и если на широкую публику, то, конечно же, нужен https
Авторы, если не подошло это по причине онлайновости, image+resize+online, то почему сами предлагаете онлайн-сервис, без исходников? И чем не устроил Gimp + nginx?
>если… на своих серверах, доступа к которым нет ни у кого
>если… на своих серверах, доступа к которым нет ни у кого
Вся суть в том, что мы предоставляем процессинг изображений в автоматическом режиме и нашему сервису абсолютно без разницы, где и кто пытается сделать ресайз. В основном, это как раз случаи, когда программист и понятия не имеет, что именно нужно ему будет обрабатывать. Вопрос исходников тут как раз не стоит остро — у грамотного специалиста не займет много времени написать подобного рода обработчик. С помощью нашего сервиса как раз и решается задача необходимости создания подобного обработчика.
> задача необходимости создания
---другими словами, осознать, что нужно создание обработчика? Я же показал ссылку на Гугл, где то же самое делается в массе других решений. Т.е. осознать есть с помощью чего, а написать несложно. Так что ваш проект не решает уникальной задачи.
---другими словами, осознать, что нужно создание обработчика? Я же показал ссылку на Гугл, где то же самое делается в массе других решений. Т.е. осознать есть с помощью чего, а написать несложно. Так что ваш проект не решает уникальной задачи.
Вы показали ссылку на Гугл, где в выдаче находятся ресурсы, позволяющее сделать ресайз, загрузив изображение вручную или указав ссылку на него. Такой подход можно использовать только если эти действия делать вручную. Мы же ставим задачу реализации такого сервиса в виде АПИ, где само использование может быть автоматизировано.
Ссылки вида thumber.io/get/1000000000x1000000000/https://habrastorage.org/getpro/habr/comment_images/f22/27f/7d8/f2227f7d86053a207ebc88ae3377af4f.jpg
успешно роняют ваше приложение. А ежели оно падает по таймауту — еще и забивают tmp, куда IM пишет временные файлы при расжатии.
Ну и, простейшим скриптом с перебором можно замусорить ваше хранилище достаточно быстро.
успешно роняют ваше приложение. А ежели оно падает по таймауту — еще и забивают tmp, куда IM пишет временные файлы при расжатии.
Ну и, простейшим скриптом с перебором можно замусорить ваше хранилище достаточно быстро.
Можно сделать это решение строго джаваскриптовым, если от ImageMagick отказаться в пользу JIMP.
Будет меньше накладных расходов на запуск внешнего (по отношению к Node.js) процесса, но чуть меньше производительность перекодировщика (JavaScript медленнее Си).
Будет меньше накладных расходов на запуск внешнего (по отношению к Node.js) процесса, но чуть меньше производительность перекодировщика (JavaScript медленнее Си).
Очень и очень полезная нужная вещь. Даже платно (если недорого:) можно использовать. Только тогда нужно будет добавить возможность заливки, без использования промежуточного сервера для хранения.
Спасибо. Внесем в список функционала возможность ручной заливки.
Можно подумать еще над кропом. Например передавать соотношение сторон (ratio), или сами размеры, и если приспичит, то и позицию кропа. Включая как пиксели так и ключи, типа тех что есть у backgroud-position.
Ну и кеширование было бы здорово, на N минут с продлением, если например передавать какой-то ключ.
В общем можно много чего придумать, и все это довольно легко.
Ну и кеширование было бы здорово, на N минут с продлением, если например передавать какой-то ключ.
В общем можно много чего придумать, и все это довольно легко.
Из софта есть еще опенсорсный thumbor.org — там REST API, умный кроп детекторами фич и физиономий через OpenCV, хранение на s3, дружелюбие к CDN и масштабируемость, опционально аплоад. Есть несколько рецептов для docker-compose, с помощью которых можно развернуть подходящую конфигурацию в облаке за полчаса.
Интересность вашего решения как сервиса зависит от SLA.
Интересность вашего решения как сервиса зависит от SLA.
https://cdn.thisislogic.ru наше детище. Используетя в продакш, не только ETag но и LastModified:) Хранится все… о боги в кластере Redis:) Доступность на данный момент простая, 2 канала и round robin. Проверяет изменение картинки на вашем сервисе в соответствии с правилом Last + опытным путем подобранным интервалом (что-то около 15 минут). Как пользоваться — все на странице написано.
А CDN — это действительно CDN? В каких регионах у вас датацентры?
Есть такое на сафари и старых андроидах. Связано с тем, что они не умеют работать с несколькими сертификатами в пределах одного ip. Надо или выделять ip или ставить default сертификат с именем, которое надо поддерживать. Я хочу выделить ip, как отдельно появится возможность. По поводу датацентров — это сильно сказано. Это всего лишь 2 HP DL360 сервера:) Центральный регион, но не москва. Пока нет возможности расширяться, ведь проект некоммерческий. Простенькое тестирование можно запустить с LoadImpact, получить соответствующие выводы о приемлемости — доступности — скорости.
Sign up to leave a comment.
Облачный ресайзинг изображений