Как правильно организовать работу с изображениями при локальной разработке/обслуживании сайтов?

Допустим есть сайт. Подключается к его обслуживанию разработчик. Он создает локально окружение схожее с продакшен. Если с кодом и базой-данных все примерно ясно, то как быть с изображениями, которые используются на сайте в новостях, блогах, товарах и прочее? Если проект маленький и изображений несколько гигабайт, то еще ладно, можно скопировать. Но как быть если изображений десятки гагабайт, не копировать же их себе локально, только ради того, чтобы корректно отображался сайт у разработчика.

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

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

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

Я намеренно не указывал о каком фреймворке идет речь, так как в данном случае мне больше интересен сам подход с работе с большим объемом фото.
  • Вопрос задан
  • 227 просмотров
Пригласить эксперта
Ответы на вопрос 3
castomi
@castomi
Серверный администратор - tickets.settin.ru
Можно проксировать изображения с продакшена.
location ~* ^.+\.(svg|svgz|ttf|jpg|jpeg|gif|png|ico|webp)$ {
    try_files $uri @prod;
    access_log off;
    expires 8d;
}
location @prod {
    proxy_pass       http://prod.ru;
}

Поясню для тех кто не вкурил, с такой организацией nginx ищет файл на сайте и если его там нет тогда запрашивает его через проксю с продакшена)
Писал на коленке, данная вещь не тестировалась нигде, так что буду признателен если отпишите как оно)

P.S. естественно этот конфиг подойдёт только для nginx, но я думаю и на апаче изобразить такое же просто. Но я конкретно с апачем редко сталкиваюсь, так что написал на том что мне понятно.
Ответ написан
Для себя решил проблему таким образом. На копиях разработчиков нет необходимости в полной базе товаров, поэтому перед созданием копии, удаляется 90% товаров, соответственно, столько же изображений. Оставшегося объёма достаточно для тестирования новых фич по изображениям. Изображения товаров - основная масса изображений. Изображения вёрстки, прочие контентные изображения переносятся на копию полностью. Но в любом случае, если копия не находит у себя запрошенного изображения, она идёт за ним на прод
Ответ написан
stanislav-belichenko
@stanislav-belichenko
Full-stack Web Developer
Для начала, для разных вариантов реализации проекта все-таки могут быть разные решения. Для фронтенд части приложения на том же React вы вообще можете не париться насчет бекенда, он забирается из интернета по http(s).

Если речь идет все-таки о разработке бекенда, или же о разработке спаянного фронтенда с бекендом на чем-то отличным от упомянутого React (и подобные библиотеки/фреймворки и приложения на них пока скорее исключение из правил), то тут опять варианты:

Первый вариант - когда у вас все равно есть некое API с этими крупными данными и оно живет где-то отдельно в сети. Или например вообще используется CDN. Ваше приложение опять же ходит туда просто по http(s), где бы оно ни было.

Второй вариант - вы пробрасываете некое защищенное подключение, но только в том случае, когда ваша разработка в данный момент затрагивает какие-то большие объемы данных, к серверу БД/папке с картинками/прочее напрямую. То есть у вас есть локальный сервер на машине разработчика или же некий тестовый в интернете, и они умеют ходить в рабочую базу по определенным условиям.

Условия могут выглядеть примерно так: Среда выполнения тестовая? Да => Мы хотим получить часть данных, которые считаем большими? Да => Использовать отдельный экземпляр подключения к БД/другое для получения данных.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через TM ID
Похожие вопросы