Где мы храним изображения?
Решение № 1 в MongoDB
Итак, первое решение - хранить изображения внутри MongoDB. Это может приспособить файлы изображения или любой тип файла. Таким образом, вы можете взять файл и привязать его к записи внутри MongoDB и сохранить его непосредственно в вашей базе данных.
При таком подходе привязка страницы описания конкретного предмета одежды с соответствующим изображением становится легкой, поскольку вы можете встроить это изображение непосредственно в разработку этой страницы, и ваш клиент будет доволен этим подходом, потому что, когда пользователь получает Страница подробного описания этого предмета одежды сопровождается изображением.
Так что это одно из возможных решений, просто возьмите изображение и сохраните его непосредственно в MongoDB.
Однако я собираюсь предположить, что это плохой подход. Причина этого заключается в том, что вы можете сообщить своему клиенту, если есть откат, в том, что он обычно будет платить за свой экземпляр Mongo в зависимости от объема хранилища, которое использует его копия Mongo.
Так что, чем больше памяти они используют, тем больше платят в месяц.
Например, в последний раз, когда я проверял использование MLab, они брали по 15 долларов за ГБ. Так что это 15 долларов из вашего кармана клиентов для размещения изображений на 1 ГБ.
Для еще одного веб-сайта электронной коммерции мы говорим о легком 3 ГБ, который переводит в 330 изображений более или менее, что равняется 15 долларам в месяц.
Так что, если один из их руководителей проектов загружает новый предмет одежды один раз в день, мы очень быстро говорим об огромных затратах.
Итак, лично я думаю, что хранение файлов любого типа непосредственно внутри MongoDB на самом деле не вариант, потому что это будет очень дорогостоящим.
Так что это только одно из возможных решений.
Решение № 2 в HD подключено к серверу
Итак, давайте посмотрим на второе решение, которое может быть доступно для вас. Вы можете использовать жесткий диск, привязанный к вашему серверу Express. Поэтому, когда это приложение развертывается в какой-либо облачной среде, такой как Heroku, Digital Ocean, Linode или AWS, вы обычно получаете жесткий диск, связанный с вашим приложением.
Так что, может быть, вы берете изображения и помещаете их на локальный жесткий диск. Именно этот подход будет пропагандироваться для подавляющего большинства онлайн-постов и статей:
Как загружать, отображать и сохранять изображения, используя node.js и экспресс
https://appdividend.com/2019/02/14/node-express-image-upload-and-resize-tutorial-example/
https://medium.com/@nitinpatel_20236/image-upload-via-nodejs-server-3fe7d3faa642
Только с тремя, которые я собрал выше, у вас есть довольно надежный план, с которого можно начать.
Каждый говорит, что возьми файл и сохрани его на свой жесткий диск. В этой статье:
https://alligator.io/nodejs/uploading-files-multer-express/
они показывают этот код:
const storage = multer.diskStorage({
destination: 'some-destination',
filename: function (req, file, callback) {
//..
}
});
Они используют библиотеку загрузки изображений под названием multer, которая предоставляет механизм diskStorage() для загрузки изображений на диск.
Так что это один из подходов, с которым в целом согласны разработчики.
Это хороший подход в контексте сопоставления «один к одному».
Проблемы с этим подходом начинают возникать, когда у нас несколько машин.
Примером этого является случай, когда у вас есть несколько машин, размещенных в Digital Ocean или Linode, где каждая среда является отдельным экземпляром.
Если у вас есть все ваши изображения, хранящиеся на прилагаемом жестком диске, и вы начинаете масштабировать сервер, у каждого из них будет свой отдельный жесткий диск.
Таким образом, у вас может быть запрос, поступающий через балансировщик нагрузки, и балансировщик нагрузки решает, куда отправить запрос, как показано на рисунке ниже:
Таким образом, проблема с вышеупомянутой архитектурой заключается в том, что образ сохраняется на одном из двух жестких дисков, а затем поступает запрос на доступ к тому же образу, но представьте, что запрос перенаправляется на другой сервер Express с другой жесткий диск, где образ не существует.
Эта проблема возникает, когда вы начинаете использовать поставщика услуг, такого как Linode или Digital Ocean, где у вас есть однозначное сопоставление между сервером и жестким диском.
Это краткосрочное решение, если это все, что вам нужно на данный момент, но как только это приложение начнет масштабироваться, оно станет проблемой.
Решение № 3 вне хранилища данных
Это третье решение, которое я использовал в прошлом для React с приложениями Node и Ruby on Rails. Фактически, мой веб-сайт Ruby on Rails использует это решение и работает на платформе Heroku.
Поэтому, когда изображение загружается, вместо того, чтобы Express API пытался сохранить файл локально, как на своем жестком диске, он получит изображение и будет использовать внешнее хранилище данных для хранения всех различных изображений из приложения.
Я использую для своего веб-сайта портфолио и то, что я использовал для Node с приложениями React, это Amazon S3, но также существуют хранилище файлов Azure и облачное хранилище Google. Эти системы предназначены для хранения огромного количества данных, и они могут представлять собой файлы любого типа, которые вы можете себе представить. Не только изображения, как в вашем случае, но и видеофайлы, аудиофайлы и так далее.
Нет ограничения на объем памяти, который вы можете иметь с S3, но вам не нужно использовать S3, но сейчас это считается отраслевым стандартом, но вы также легко можете использовать Azure и Google. Облако.
Преимущество этого решения, которое, я думаю, оценят ваши клиенты, Amazon S3 взимает с вас два цента за гигабайт в месяц за хранение.