Къде съхраняваме изображения?
Решение № 1 в MongoDB
Така че първото решение е да съхранявате изображенията вътре в MongoDB. Може да побира файлове с изображения или всеки тип файл. Така че можете да вземете файл и да го свържете със запис в MongoDB и да го запишете директно във вашата база данни.
С този подход обвързването на страница с описание на конкретен артикул от облекло със съответното му изображение става лесно, защото можете да вградите това изображение директно във вашата разработка на тази страница и вашият клиент ще бъде доволен от този подход, защото когато потребителят извлече подробно описание страница на тази дреха, която идва с изображението.
Така че това е едно възможно решение, просто вземете изображението и го съхранете директно в MongoDB.
Аз обаче смятам, че това е лош подход. Причината за това, че можете да кажете на клиента си, ако има отхвърляне, е, че той обикновено ще плаща за своя Mongo екземпляр по отношение на количеството място за съхранение, което тяхното Mongo копие използва.
Така че колкото повече хранилище използват, толкова повече пари плащат на месец.
Например последния път, когато проверих използването на MLab, те таксуваха $15 на GB. Така че това са $15 от джоба на вашите клиенти за хостване на изображения на стойност 1 GB.
За още един уебсайт за електронна търговия говорим за 3 GB лесно, което се превежда в 330 изображения повече или по-малко, равно на 15 $ на месец.
Така че, ако един от техните ръководители на проекти качва нова дреха веднъж на ден, говорим за огромни разходи много бързо.
Така че, лично аз смятам, че съхраняването на какъвто и да е тип файл директно в MongoDB наистина не е опция, защото ще бъде много скъпо.
Така че това е само едно възможно решение.
Решение № 2 в HD, прикрепено към сървър
Така че нека разгледаме второ решение, което може да е достъпно за вас. Може да използвате твърд диск, който е свързан с вашия Express сървър. Така че, когато това приложение се внедри в някаква облачна среда като Heroku, Digital Ocean, Linode или AWS, обикновено получавате твърд диск, свързан с вашето приложение.
Така че може да вземете изображенията и да ги поставите в локалния твърд диск. Този подход е това, което по-голямата част от онлайн публикациите и статиите ще подкрепят:
Как за качване, показване и запазване на изображения с помощта на node.js и express
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 with Node и Ruby on Rails. Всъщност моят уебсайт с портфолио Ruby on Rails използва това решение и се намира на платформата Heroku.
Така че, когато изображението бъде качено, вместо Express API да се опитва да съхранява файла локално като на собствения си твърд диск, той ще вземе изображението и ще използва външно хранилище за данни, за да съхранява всички различни изображения от приложението.
Този, който използвам за уебсайта си за портфолио и това, което съм използвал за приложения на Node с React, е Amazon S3, но също така съществува Azure File Storage и Google Cloud Storage. Тези системи са направени да съхраняват огромно количество данни и могат да бъдат всякакъв тип файл, който можете да си представите. Не само изображения като във вашия случай, но и видео файлове, аудио файлове и т.н.
Няма ограничение за количеството хранилище, което можете да имате със S3, но не е нужно да използвате S3, но в момента той се разглежда като индустриален стандарт, но можете лесно да използвате също толкова добре Azure и Google Cloud.
Предимството на това решение, което мисля, че вашият клиент ще оцени, Amazon S3 ви таксува около две стотинки на гигабайт на месец за съхранение.
