Closed ivchicano closed 3 years ago
The topic require to decide an approach since: 1) the API sit in the backend container 2) it could be complex to have the frontend to issue a API call for retrieving images
Proposal could be: 1) we define a folder that is mounted both in the backend container and in the nginx container 2) we define a location in nginx in the migrant and pa and ngo servers that point all to the same folder where the images are placed 3) you save a relative path (only "/micado_images") in the content so that nginx will be able to give the image to all applications (we will have the PA application that wil need to be able to show the image and also the migrant app so the path needs to be the same even if we change the domain) 4) you need to create and API in backend for saving the image and change the name of the file to something with UUID and not the actual name 5) you need to have the "choose the image" part that reads from the mounted folder
This in production ... in development is a mess Since we do not have nginx, but considering that once we have the same folder mounted in containers you can develop the parts independently
Can we deploy a new nginx domain that contains the images? It could share a volume with the backend. I think this will make it easier (but needs a new domain i.e. images.micadoproject.eu). When uploading loopback will save the images in this volume, and the new nginx container distributes them. This will also make it so development isn't as messy I think. Let me know what you think.
This should be fixed by API
fixed
We should have a way to upload images. Currently in topics and user type settings the image is encrypted to base64. This is fine for icons but for bigger images (such as the ones added via de editor) the overhead can get quite heavy (roughly 33% more space consumed in storage and in network transit). I propose saving to the backend filesystem.