Carrierwave или Dragonfly

Я изучал инструменты загрузки файлов rails, и те, которые казались мне наиболее привлекательными и интересными, были несущими и стрекозами.

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

Мне было интересно, есть ли у людей какие-либо ссылки на тест производительности или любой тест, который сравнивает эти два.

Кроме того, просто любопытно мнение людей о том, что они предпочитают, и, конечно, почему они предпочитают это.

Ответ 1

В зависимости от настройки. Как пишет Senthil, до тех пор, пока у вас есть кэш-прокси впереди, это прекрасно со Стрекозой.

Но если вы используете встроенное кэширование рельсов, Carrierwave будет работать лучше, поскольку файлы могут быть загружены без какой-либо обработки. Если вы не выполняете какую-либо обработку, это не имеет значения.

Вот как я обобщил, рассматривая оба для изображений в проекте с помощью Mongomapper:

Carrierwave:

Pros
- Генерирует превью на загрузку (экономит время процессора)
- Может использовать файлы непосредственно из статического/кэшированного документа
- Не нужен кеш-сервер
- Поддерживает различные резервные копии хранилища (S3, Cloudfiles, GridFS, обычные файлы), при необходимости легко расширяется до новых типов хранилищ.
Cons
- Создает большие пальцы при загрузке (diffucult для создания новых больших размеров)
- Не поддерживает mongomapper
- Использует хранилище для каждого файла/большого пальца. Если вы используете обычное хранилище файлов, у вас может закончиться inodes!

Dragonfly:

Pros
- Должен работать с mongomapper, поскольку он только расширяет ActiveModel
- Генерирует большие пальцы руки на лету (проще создавать новые макеты/превью)
- Сохраняется только один файл! Экономит место:)
Cons
- Едет процессор по каждому запросу, если у вас нет кэш-прокси, rack:: cache или аналогичного.
- Невозможно получить доступ к файлам большого пальца в случае необходимости.

Я закончил использовать оба в конце.

Будущее желание для несущей волны снова заменить MongoMapper. После использования обоих в разных ситуациях я обнаружил, что функции в MongoMapper (ветки rails3) всегда работают, и их легко расширить с помощью плагинов. Не могу сказать то же самое для Mongoid, но это может измениться.

Ответ 2

Я использую dragonfly просто потому, что несущая волна потеряла поддержку mongomapper, и скрепка не работает mongomapper без каких-либо хаков.

Dragonfly делает обработку "на лету", т.е.

предназначен для использования за кэш-прокси, например, лак, кальмар или Rack:: Cache, так что в то время как первый запрос может занять некоторое время, затем запросы должны быть супер-быстрыми!

Ответ 3

Скрепка

Скрепка предназначена для простой файловой вставки для Active Record. Цель этого заключалась в том, чтобы максимально упростить настройку и обрабатывать файлы так же, как и другие атрибуты. Это означает, что они не сохраняются в их конечных местоположениях на диске и не удаляются, если они установлены в нуль, до тех пор, пока не будет вызываться ActiveRecord::Base#save. При необходимости он управляет проверками, основанными на размере и присутствии. Он может преобразовать назначенное изображение в миниатюры, если это необходимо, а предварительные требования так же просты, как установка ImageMagick (что для большинства современных систем на базе Unix так же просто, как и установка правильных пакетов). Прикрепленные файлы сохраняются в файловой системе и упоминаются в браузере по легко понятной спецификации, которая имеет разумные и полезные значения по умолчанию.

Преимущества

валидации, Paperclip представляет несколько валидаторов для проверки вашего вложения: AttachmentContentTypeValidator AttachmentPresenceValidator AttachmentSizeValidator
Удаление приложения Установите атрибут на nil и сохраните. @user.avatar = nil @user.save
Скрепка лучше для органической среды Rails с использованием activerecord, а не для всех других альтернатив. Paperclip намного проще обрабатывать для начинающих разработчиков рельсов, а также имеет расширенные возможности для продвинутого разработчика.
Огромный поклонник Paperclip, потому что он не требует RMagick, очень легко настроить его на отправку до Amazon S3 и объявить все в моделях (валидации и т.д.), что делает вещи чистыми.
Что касается множественных загрузок файлов и обратной связи с ними, то оба варианта возможны как с помощью программы Paperclip, так и с Attachment_fu, но для нормальной работы требуется как минимум локоть-смазка с iframes и Apache.

CarrierWave

Этот камень обеспечивает простой и чрезвычайно гибкий способ загрузки файлов из приложений Ruby. Он хорошо работает с веб-приложениями на стойке, такими как Ruby on Rails.

Преимущества

Интеграция объектов простой модели. Добавление одного атрибута image для ссылки на загруженное изображение.
"Магические" методы моделирования для загрузки и удаленной загрузки изображений.
Интеграция загрузки файлов HTML с использованием стандартного тега файла и другого скрытого тега для поддержки уже загруженной "кешированной" версии.
Прямой интерфейс для создания производных версий изображений с различными размерами и форматами. Инструменты обработки изображений прекрасно скрыты за кулисами.
Методы моделирования для получения общедоступных URL-адресов изображений и их измененных версий для встраивания HTML.
если встроенное кэширование рельсов, Carrierwave будет работать лучше, поскольку файлы могут быть загружены без какой-либо обработки. Если вы не выполняете какую-либо обработку, это не имеет значения.
Генерирует превью на загрузку (экономит время процессора)
Может использовать файлы непосредственно из статического/кэшированного документа
Не нужен кеш-сервер
Поддерживает различные серверы хранения (S3, Cloudfiles, GridFS, обычные файлы), при необходимости легко расширяется до новых типов хранилищ. Один из фактов, что он не загромождает ваши модели с конфигурацией. Вместо этого вы можете определить классы загрузчика. Это позволяет вам легко повторно использовать, расширять и т.д. Конфигурацию загрузки. Больше всего нам понравилось то, что CarrierWave очень модульный. Вы можете легко переключить механизм хранения между локальной файловой системой, облачным AWS S3 и т.д. Вы можете переключить модуль обработки изображений между RMagick, MiniMagick и другими инструментами. Вы также можете использовать локальную файловую систему в своем dev env и переключиться на хранилище S3 в производственной системе. Carrierwave имеет хорошую поддержку для внешних вещей, таких как DataMapper, Mongoid, Sequel и даже может использоваться с управлением сторонними изображениями, такими как cloudinary. Решение кажется наиболее полным с поддержкой для чего-либо, но решение также намного более беспорядочно (для меня по крайней мере), так как есть намного больше кода, который вам нужно обработать. Необходимо оценить модульный подход, который принимает CarrierWave. Его агностик относительно того, какой из популярных клиентов S3 вы используете, поддерживая оба aws/s3 и right_aws. Его также ORM агностик и не тесно связан с Active Record. Тесное сцепление скрепки вызвало у нас некоторое горе на работе.

Недостатки

Вы не можете проверить размер файла. Существует статья wiki, в которой объясняется, как это сделать, но она не работает.
Проверки целостности не работают при использовании MiniMagick (очень удобно, если вас беспокоит использование ОЗУ). Вы можете загрузить поврежденный файл изображения, а CarrierWave сначала выдает ошибку, но в следующий раз проглотит его.
Вы не можете удалить исходный файл. Вы можете изменить его размер, сжать и т.д. Существует статья wiki, объясняющая, как это сделать, но опять же она не работает.
Это зависит от внешних библиотек, таких как RMagick или MiniMagick. Paperclip работает непосредственно с командной строкой преобразования (ImageMagick). Итак, если у вас есть проблемы с Minimagick (у меня было), вы потеряете часы погружения в поиске Google. И RMagick, и Minimagick оставлены на момент написания этой статьи (я связался с автором Minimagic, без ответа).
Ему нужны некоторые файлы конфигурации. Это рассматривается как преимущество, но мне не нравится иметь одиночные файлы конфигурации вокруг моего проекта только для одного драгоценного камня. Конфигурация в модели кажется мне более естественной. В любом случае, это вопрос личного вкуса.
Если вы обнаружите ошибку и сообщите об этом, команда разработчиков действительно отсутствует и занята. Они скажут вам, чтобы исправить ошибки самостоятельно. Это похоже на личный проект, который улучшается в свободное время. Для меня это не подходит для профессионального проекта с предельными сроками.
Не поддерживает mongomapper
Использует хранилище для каждого файла/большого пальца. Если вы используете обычное хранилище файлов, у вас может закончиться inodes!

Dragonfly

Впечатляющая вещь о Dragonfly, то, что отделяет ее от большинства других плагинов обработки изображений, заключается в том, что она позволяет изменять размер изображения на лету без изменений.
Не нужно настраивать размер эскиза или другие действия в отдельном файле - это огромное время и сбой. Это делает возможным просмотр кода Rails, например image_tag @product.image.thumb('150x150#').
Магия становится возможной благодаря кешированию. Вместо того, чтобы создавать обработанную версию при загрузке и затем ссылаться на отдельные версии изображения, плагин генерирует изображения по мере их запроса. Хотя это проблема для первой загрузки, вновь созданное изображение http кэшируется для всех последующих нагрузок, по умолчанию используется Rack:: Cache, хотя доступны другие более надежные решения, если масштабирование станет проблемой.

Преимущества

Часто ли меняю размер изображения? Пример: если вы хотите, чтобы ваши пользователи меняли размер своих изображений (или гибкость по размеру по какой-либо другой причине), или очень быстрая разработка. Да: Стрекоза Нет: либо Carrierwave, либо Paperclip.
Может использоваться с mongomapper без проблем
Производительность должна быть прекрасной, если вы используете прокси-сервер кэширования
Должен работать с mongomapper (он только расширяет ActiveModel)
Генерирует большие пальцы руки на лету (проще создавать новые макеты/превью)
Сохраняется только один файл! Экономит место
Обработка выполняется "на лету" (предполагается, что она используется за прокси-сервером, таким как Varnish, Squid или Rack:: Cache, так что, хотя первый запрос может занять некоторое время, последующие запросы должны быть супер-быстрыми)

Недостатки

Едет процессор по каждому запросу, если у вас нет кэширующего прокси, rack::cache или аналогичного.
Невозможно получить доступ к файлам большого пальца в случае необходимости.

Ссылки

Ответ 4

Другие люди писали довольно хорошие резюме, я просто хотел бы сказать, что по нашему опыту Dragonfly setup требовало большего обслуживания, и из-за небрежности некоторых разработчиков (разработчиков) по пути мы также застряли с большим количеством сиротских изображений, которые задержались после того, как оригинал был удален. Это не случилось бы с ванильной несущей волной. Постскриптум Мы перенеслись в облачную (и используем с ней несущую волну) и довольны этим.