Solución:
¿Dónde almacenamos las imágenes?
Solución n. ° 1 en MongoDB
Entonces, la primera solución es almacenar las imágenes dentro de MongoDB. Puede acomodar archivos de imagen o cualquier tipo de archivo. Entonces puede tomar un archivo y vincularlo a un registro dentro de MongoDB y guardarlo directamente en su base de datos.
Con este enfoque, vincular una página de descripción de una prenda de vestir en particular con su imagen correspondiente se vuelve fácil porque puede incrustar esta imagen directamente en el desarrollo de esa página y su cliente estaría contento con ese enfoque porque cuando el usuario recupera una descripción detallada página de esa prenda de vestir viene con la imagen.
Entonces esa es una posible solución, simplemente tome la imagen y guárdela directamente en MongoDB.
Sin embargo, voy a sugerir que este es un mal enfoque. La razón de eso, puede decirle a su cliente si hay un rechazo es que generalmente pagarán por su instancia de Mongo en términos de la cantidad de almacenamiento que usa su copia de Mongo.
Por lo tanto, cuanto más almacenamiento usan, pagan más dinero al mes.
Por ejemplo, la última vez que verifiqué el uso de MLab, estaban cobrando $ 15 por GB. Así que son $ 15 del bolsillo de sus clientes por alojar imágenes por valor de 1GB.
Para otro sitio web de comercio electrónico, estamos hablando de 3GB easy, lo que se traduce en 330 imágenes más o menos, lo que equivale a $ 15 al mes.
Entonces, si uno de sus gerentes de proyecto está cargando una nueva prenda de vestir una vez al día, estamos hablando de un costo tremendo muy rápidamente.
Entonces, personalmente, creo que almacenar cualquier tipo de archivo directamente dentro de MongoDB realmente no es una opción porque será muy costoso.
Así que esa es solo una posible solución.
Solución n. ° 2 en HD adjunta al servidor
Así que veamos una segunda solución que podría estar disponible para usted. Puede usar un disco duro que esté vinculado a su servidor Express. Entonces, cuando esta aplicación se implementa en algún entorno de nube como Heroku, Digital Ocean, Linode o AWS, generalmente obtiene un disco duro asociado con su aplicación.
Entonces, tal vez tome las imágenes y las coloque dentro del disco duro local. Este enfoque es el que abogará la gran mayoría de publicaciones y artículos en línea:
Cómo cargar, mostrar y guardar imágenes usando node.js y 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
Solo con los tres que reuní anteriormente, tienes un modelo bastante sólido para comenzar.
Todos dicen que tome el archivo y guárdelo en su disco duro local. En este artículo en particular:
https://alligator.io/nodejs/uploading-files-multer-express/
están mostrando este código:
const storage = multer.diskStorage({
destination: 'some-destination',
filename: function (req, file, callback) {
//..
}
});
Están usando la biblioteca de carga de imágenes llamada multer que proporciona el diskStorage() motor para subir imágenes al disco.
Así que este es un enfoque con el que la comunidad de desarrollo en general está de acuerdo.
Este es un buen enfoque en el contexto de un mapeo uno a uno.
Los problemas con este enfoque comienzan a surgir cuando tenemos varias máquinas.
Un ejemplo de esto es si tiene varias máquinas alojadas en Digital Ocean o Linode donde cada entorno es una instancia separada.
Si tiene todas sus imágenes almacenadas en el disco duro adjunto y luego comienza a escalar su servidor, cada una tendría su propio disco duro separado.
Por lo tanto, es posible que tenga una solicitud que ingrese a través de un balanceador de carga y el balanceador de carga decide dónde enviar la solicitud como en el diagrama a continuación:
Entonces, el problema con la arquitectura anterior es si la imagen se guarda en uno de los dos discos duros y luego entra una solicitud para acceder a la misma imagen, pero imagina que la solicitud se enruta al otro servidor Express con un disco duro diferente. donde la imagen no existe.
Este es un problema que surge cuando comienza a utilizar un proveedor de servicios como Linode o Digital Ocean, donde tiene un mapeo uno a uno entre el servidor y el disco duro.
Es una solución a corto plazo si eso es todo lo que necesita por ahora, pero una vez que la aplicación comience a escalar, será un problema.
Solución n. ° 3 fuera del almacén de datos
Esta tercera solución es una que he usado en el pasado con las aplicaciones React with Node y también con las aplicaciones Ruby on Rails. De hecho, mi sitio web de cartera Ruby on Rails utiliza esta solución y se encuentra en la plataforma Heroku.
Entonces, cuando se carga la imagen, en lugar de que la API Express intente almacenar el archivo localmente como en su propio disco duro, tomará la imagen y usará un almacén de datos externo para almacenar todas las diferentes imágenes de la aplicación.
El que uso para el sitio web de mi cartera y el que he usado para las aplicaciones Node con React ha sido Amazon S3, pero también existe Azure File Storage y Google Cloud Storage. Estos sistemas están hechos para contener una enorme cantidad de datos y pueden ser cualquier tipo de archivo que puedas imaginar. No solo imágenes como en tu caso, sino archivos de video, archivos de audio, etcétera.
No hay límite para la cantidad de almacenamiento que puede tener con S3, pero no tiene que usar S3, pero se considera un estándar de la industria en este momento, pero también puede usar Azure y Google Cloud fácilmente.
El beneficio de esta solución que creo que su cliente apreciará es que Amazon S3 le cobra como dos centavos por gigabyte al mes por almacenamiento.