Каков наилучший подход для генерации миниатюр и загрузки в корзину s3 в узле?

Question

Я разрабатываю пример приложения, в котором мой сервер работает на NodeJ, а клиент использует React.Это приложение будет иметь дело с кучей фотографий, так что пользователь может загружать фотографии, а серверная часть сохранит его в корзину s3.Кроме того, мне нужны некоторые преобразования, такие как создание миниатюр разных размеров, наиболее вероятно, две миниатюры размером 100 × 100 пикселей и 200 × 200 пикселей.процесс?

Я также прошел через несколько вещей, таких как cloudinary , который кажется хорошим вариантом для преобразования изображения на лету.

Теперь у меня есть нескольковопросы по этому вопросу, связанные с лучшими практиками.

1. Должен ли я подключиться к своему серверу приложений (NodeJs) для загрузки / преобразования изображений?Причина, по которой я спрашиваю, состоит в том, что я попробовал cloudinary , когда загрузка изображения даже не попадает на сервер приложений.

2. Или это нормально, если ударить сервер приложений исоздайте там миниатюры и загрузите их в s3.

3. Нажмите сервер приложений, загрузите изображение в корзину s3 и активируйте функцию lambda , чтобы выполнить все преобразования (Чтоэто преимущество?)

Спасибо за ваше терпение за чтение этих вопросов.Я открыт для любых предложений, идей и опасений.

Answer 1

Это зависит от ваших требований, но я постараюсь выделить преимущества и недостатки каждого из них.

Прежде всего, некоторые вещи, которые необходимо учитывать:

• Сколько изображений будет загружено?
• Как часто будут доступны эти изображения и эскизы?
• Как быстро после загрузки должны быть доступны эскизы?Почти мгновенно, или допустима задержка в несколько секунд?
• Насколько велики эти изображения?
• Что важнее: эксплуатационные расходы или затраты на разработку / время?

Вам необходимо понять все эти вещи, чтобы иметь возможность эффективно сравнивать.

Ваши варианты на самом деле не являются тремя различными вариантами.

Вариант 1 - это независимое архитектурное решение.Независимо от того, отправляете ли вы все или что-либо обратно через сервер приложений, вам доступны sdks для AWS и Cloudinary как для внешнего, так и для внутреннего интерфейса.Но если вы помещаете все в интерфейс, будьте осторожны, как вы управляете своими ключами.В любом случае, будьте осторожны, но, как правило, все забывают, что это код внешнего интерфейса, который видят все.

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

Если вы выполняете всю работу на сервере приложений, убедитесь, что он имеет правильный размер для борьбы с рабочей нагрузкой и может справиться с повторными попытками, есливсе идет не такЭто, вероятно, самая большая работа для вас и, очевидно, будет больше загружать ваш сервер.Увеличение размера вашего сервера, вероятно, будет стоить дороже, чем использование лямбд, если ваша пропускная способность не очень постоянна, очень высока, и вы можете точно их специфицировать.

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

Существует множество примеров кода для обоих сценариев, но, вероятно, больше для AWS lambda (caveat - основано на 30).секунд поиска в Google).

Вы фактически не называли это как вариант, но Cloudinary будет выполнять манипуляции с изображениями на лету (как вы заявили в своем вступлении).Это означает, что вам на самом деле не нужно создавать и сохранять эскизы, просто вызовите исходное изображение с указанным размером в URL.Можете ли вы жить с задержкой?Большую часть времени это едва узнаваемо.Можете ли вы жить со стоимостью?Будь то деньги или расходование бесплатных кредитов.