Офер за 1 день в команду BetterMe (Frontend Hiring, JavaScript/React/Redux)
×Закрыть

Статические файлы и деплой нового war’а

У меня есть приложение, написанное на Grails и в конеченом счете это конечно war-файл. Я его деплою на сервер и все работает отлично.
В приложении предусмотрена админка, в которой можна к примеру изменять статьи/товары. Им можна добавлять/изменять контент, в том числе и картинки. В случае если я дописал какой-либо функционал, то я деплою новый war на сервер.
Вопрос:
Как мне «оставлять» статические файлы(картинки), загруженные ранее менеджером через админку ? Поскольку они складываются в распакованный war, а я при необходимости сделать upgrade деплою новый war, то все загруженные ранее картинки будут утеряны. Может кто-то знает какие-либо best practices, расскажите пожалуйста.
Спасибо за внимание.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Как мне «оставлять» статические файлы(картинки), загруженные ранее менеджером через админку ?

Это называется не «статические файлы» (это всякие ЦССы, ДжСы), а пользовательские файлы.

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

А как насчет сохранять картинки в БД ?

В случае с большими файлами будут потери производительности. Для скачивания файла нужно будет обращаться к БД, получать содержимое BLOB-поля, формировать HTTP заголовки и т.д. Если не кешировать, то будет слишком большая нагрузка на сервер. Если кешировать и сохранять на диск, то зачем изначально хранить в БД. Из достоинств — возможность полного контроля над доступом к файлу.

Как вариант — хранить в базе ссылку на файл в облаке, например с использованием Amazon S3.

А как насчет забыть про хибернейт? :)
Если вы используете ОРМ, то велика вероятность завтыкать и постоянно вытягивать БЛОБ из БД — минус производительности.
Второй момент: Картинки — это так же статика (как вы верно заметили) и несмотря на то что они пользовательские, рано или поздно за вам захочется вынести их на сервер статики. В случае с хранинием в БД такой фокус в пролете. Да и чтобы вернуть 304 прийдет тянуть что-то из БД и самому решать поменялось или нет, а так за вас все сделает веб-сервер.

Вот я тоже считаю, что хранение в БД плохой вариант, но почему-то в Grails все пропагандируют именно этот подход.

Для проектов с небольшой нагрузкой такое прокатит.

Подписаться на комментарии