I am using meteor-upload to upload images to my server. They are saved into the public folder which is
…/programs/web.browser/app/
while the server is running.
If I put an image in my project and then build it, I will be able to use the image or access it directly.
But if someone uploads an image via a form in the website in a folder like :
…/programs/web.browser/app/images/myupload.png
I will not be able to access it and I will get this error :
router.js:347 There is no route for the path: /images/avatar/avatar-LETdQd4A29c2bQHRd.png
So what ? I can’t have dynamically added static objects in my public folder ?
Is there a way to tell FlowRouter that all files and folders under /images should just be “let through”.
Don’t do this! Files stored in /public are included as part of your deployed application bundle, so the next time you deploy you’ll overwrite anything you added through the running application. Also, by storing these images on the filesystem you’ll be severely hampering your ability to scale horizontally. You’re better off storing them in a database using something like cfs:gridfs, or using a third party storage system like Amazon’s S3 (leveraging the S3 npm package).
I saw that storing them in public is not a good idea and I found a way to store them outside of the project and use Picker to send them to the clients.
Now, I can understand why it would be better to have them outside of the server but I will only store one image per accounts and then one 1080p image per entry.
Amazon’s S3 is not really free, what can I gain from it ? If I store locally, have my daily db+images backup and my weekly snapshot what is there more ?
One day I won’t have enough space to store and I will have to get more space but I feel like having them locally is not that bad for my small project.
By using a service like S3, or by storing your uploaded files in a database, you’re future proofing your app from a scalability point of view. If you know your app isn’t ever going to need to scale to handle a lot of users, then by all means use the file system. If you store uploaded files in S3 or in a database though (which requires a fairly minimal amount of extra upfront work), then if you ever need to deploy your application across multiple servers (if needs grow), your uploaded files will be accessible to each deployed instance of your application, on each server (as long as the share the same S3/database access). If you store uploaded files on the filesystem you’ll then have to take care of keeping these files in synch yourself across servers (which isn’t even an option on some platforms, like Galaxy for example).
Seems like a good idea. I looked at the npm s3 docs and I found that I need to upload to the server and then send it to S3. But I don’t see any information on getting an url to not have to download it on the server (<img src="amazons3..../myid/myimages/image.png" >).
How to do most people use this service ?
They sync a folder ? Upload and download manually ?
Files stored in /public are included as part of your deployed application bundle, so the next time you deploy you’ll overwrite anything you added through the running application. Also, by storing these images on the filesystem you’ll be severely hampering your ability to scale horizontally. You’re better off storing them in a database using something like