I have searched far and wide, but everyone seems to be focused on how to upload images to a NodeJs REST API. I'm already using Multer for that. Now I need to figure out how to download the private images through my REST API. When I say "private" I obviously mean that the images are specific to each user who is logged in - they are NOT publicly accessible nor are they accessible to anyone who is logged in except for the user who uploaded them. I tried ExpressJs's sendFile(), but it sends a binary file that is seemingly impossible for the client to transform and insert into an img element because it's not a blob. But what I'm REALLY asking is: Is there a mechanism/library already available to handle this, like Multer - except for DOWNLOADING PRIVATE images and letting me insert them into img elements?
Thanks for your suggestions. I'm using Vue and Vuetify on the front end, by the way.
Final solution is to use image-to-base64 (https://www.npmjs.com/package/image-to-base64) on server and download the base64 string and plug it into the img src as src="data:image/(ext);base64,...". Ref: https://en.wikipedia.org/wiki/Data_URI_scheme As you know it makes the download 33% bigger, but that's the cost of privacy! Have fun!!
Related
Am not saying that i dont know how because i tried it before using multer and it works perfectly fine but the thing is these images get saved to a foldet called uploads with a namd and an id that i generatr using js
What i want to know : is this the propper way of doing it and if so wherr does that folder go to after hosting your website and does it contain alll the images from my website, i mean it will be a really large folder so where does it go to when hosting ??
PS: And another thing whenever i go to youtube or facebook etc i see a domain like i.ytimg.com containing these images so how is that acheived
I don't know if my reply would be helpful, but the way I use it is I save the image in a mongoDB database (Buffer) and just load it from the database.
I can't find a response to my question.
I'm building a React app using NodeJS and CRA and i need to implement an uploading avatar system. But i'm not sure where to save the uploaded image. My Node server serve a static folder 'public', so does i need to save images in /public/avatar? But each time i will make update on the app and re-build the client-side folder, this will overwrite the public folder and remove all the previous uploaded avatar ? I'm right ? So what are you suggesting me ?
Thanks,
There are multiple locations that you can store your user uploaded images, though storing them in your public is probably not the best location.
In the case where you were using a database like MongoDB, you could store the image inside Mongo using gridfs and serve the data using a route when you retrieve the user information. Similarly, you can also store in the database a path to the file, and return the path, or the file data, from the route as well.
Be careful with user uploads, however, as arbitrarily allowing uploaded data can lead to unanticipated results if you're not careful.
You could also use Gravatar (https://gravatar.com/).
User can choose an avatar assigned to their mail address hash, or use an automatically generated one by default.
Though with this solution you cannot let users change their avatar directly on your website.
It is widely used on well known websites like StackOverflow.
I would like to know what is the best way to handle image uploading and saving the reference to the database. What I'm mostly interested is what order do you do the process in?
Should you upload the images first in the front-end (say Cloudinary), and then call the API with result links to the images and save it to the database?
Or should you upload the images to the server first, and upload them from the back-end and save the reference afterwards?
OR, should you do the image uploading after you save the record in the database and then update it once the images were uploaded?
It really depends on the resources, timeline, and number of images you need to upload daily.
So basically if you have very few images to upload then you can upload that image to your server then upload it to any cloud storage(s3, Cloudinary,..) you are using. As this will be very easy to implement(you can find code snippet over the internet) and you can securely maintain your secret keys/credential to your cloud platform on the server side.
But, according to me best way of doing this will be something like this. I am taking user registration as an example
Make server call to get a temporary credential to upload files on the cloud(Generally, all the providers give this functionality i.e. STS/Signed URL in AWS).
The user will fill up the form and select the image on the client side. When the user clicks the submit button make one call to save the user in the database and start upload with credentials. If possible keep a predictable path for upload. Like for user upload /users/:userId or something like that. this highly depends on your use case.
Now when upload finishes make a server call for acknowledgment and store some flag in the database.
Now advantages of this approach are:
You are completely offloading your server from handling file operations which are pretty heavy and I/O blocking and you are distributing that load to all clients.
If you want to post process the files after upload you can easily integrate this with serverless platforms and do that on there and again offload that.
You can easily provide retry mechanism to your users in case of file upload fails but they won't need to refill the data, just upload the image/file again
You don't need to expose the URL directly to the client for file upload as you are using temporary Creds.
If the significance of the images in your app is high then ideally, you should not complete the transaction until the image is saved. The approach should be to create an object in your code which you will eventually insert into mongodb, start upload of image to cloud and then add the link to this object. Finally then insert this object into mongodb in one go. Do not make repeated calls. Anything before that, raise an error and catch the exception
You can have many answers,
if you are working with big files greater than 16mb please go with gridfs and multer,
( changing the images to a different format and save them to mongoDB)
If your files are actually less than 16 mb, please try using this Converter that changes the image of format jpeg / png to a format of saving to mongodb, and you can see this as an easy alternative for gridfs ,
please check this github repo for more details..
I want to upload images from the client to the server. The client must see a list of all images he or she has and see the image itself (a thumbnail or something like that).
I saw people using two methods (generically speaking)
1- Upload image and save the binaries to MongoDB
2- Upload an image and move it to a folder, save the path somewhere (the classic method, and the one I implemented so far)
What are the pros and cons of each method and how can I retrieve the data and show it in a template in each case (getting the path and writing to the src attribute of and img tag and sending the binaries) ?
Problems found so far: when I request foo.jpg (localhost:3000/uploads/foo.jpg) that I uploaded and the server moved to a known folder, my router (iron router) fails to find how to deal with the request.
1- Upload image and save the binaries to MongoDB
Either you limit the file size to 16MB and use only basic mongoDB, either you use gridFS and can store anything (no size limit). There are several pro-cons of using this method, but IMHO it is much better than storing on the file system :
Files don't touch your file system, they are piped to you database
You get back all the benefits of mongo and you can scale up without worries
Files are chunked and you can only send a specific byte range (useful for streaming or download resuming)
Files are accessed like any other mongo document, so you can use the allow/deny function, pub/sub, etc.
2- Upload an image and move it to a folder, save the path somewhere
(the classic method, and the one I implemented so far)
In this case, either you store everything in your public folder and make everything publicly accessible using the files names + paths, either you use dedicated asset delivery system, such as an ngix server. Either way, you will be using something less secure and maintenable than the first option.
This being said, have a look at the file collection package. It is much simpler than collection-fs and will offer you everything you are looking for out of the box (including a file api, gridFS storing, resumable uploads, and many other things).
Problems found so far: when I request foo.jpg
(localhost:3000/uploads/foo.jpg) that I uploaded and the server moved
to a known folder, my router (iron router) fails to find how to deal
with the request.
Do you know this path leads to your root folder public/uploads/foo.jpg directory? If you put it there, you should be able to request it.
I'm currently considering developing a Meteor node.js app, but am struggling with how best to handle uploading of user images. In particular, I want to create a photography website that will allow the photographer to upload images in an 'admin' section, and these images will then be displayed on the website. I need to create a thumbnail of these images, and save the respective URLs to the database. I'm struggling with how to best accomplish this in meteor.
Is my best bet to use something like s3 combined with an AWS process for generating thumbnails?
Or should I save and host the images directly in the Meteor/node session?
Or should I scrap Meteor and use something like Express.js for this project?
Why don't you just use something like Filepicker.io to handle uploading and hosting images and simply store the image unique url (given to you by filepicker in the callback)?
Thumbnails can also be dynamically generated by Filepicker (using simple url modifications).
Cloudinary is a nicer alternative to filepicker when it comes to images, but integration process will be messier.
I would store the images on the filesystem, not in a database. If you have a unique id, you can use that as part of the url, for example an id of the item the image belongs to. Might look like this:
./uploads/img-<id>-<size>.jpg
You can write to disk and resize if necessary with node-imagemagick and your cdn should just poll these images from time to time. Not exactly sure how that part would work in terms of including the url to the image in the html.