I’m trying to get a setup running where one Meteor instance can send binary image data to another Meteor instance, which writes that data to an image file in /public/uploads and then serves that image for subsequent requests.
The issue I’ve run into is that Meteor restarts itself everytime it detects the /public/ directory has changed. Can I safely disable this functionality without also breaking its ability to serve the new image files?
Hey Nathan! What in ur opinion would be the best method of storing images for a project that has gigs of it. Images are constantly being uploaded by the users.
I suppose it would not be a good idea to store them in the DB, assuming it’s size…
@avalanche1 Any cloud storage system would work well (from Amazon, Rackspace or Google).
There are huge advantages for not storing data locally on your server. And, to get the same architecture benefits without a cloud service, you’d probably end up building a complicated storage API… so why not use one that already exists.
The only downside is the complexity of understanding the API’s / designing your app around URL signing / “fetching” resources instead of just grabbing them locally.
Personnally i store images outside the meteor project (or directly in db) and i create a server route to access them from client. Advantages : no need to know how works nginx, and it’s quick to setup when you are a developper. Disavantages : each call on those routes will require nodeJs resources, so it takes place in its event Loop, whereas it’s really useless. There is no need to use nodeJs here…
I did this because i’m not good on system operation, but 2 years ago the community was not so huge and i needed to go on quickly
@nathan_muir What are the advantages of not storing data locally? The APIs that cloud services provide are not required when storing files locally, because fs module already does much more than these APIs can provide. I am not able to see the advantages of storing files on cloud. I’m building an app and I am storing files locally and your post is making me re-evaluate my decisions. It’d be great if you can elaborate on advantages of cloud storage providers vs locally storing the files.
When you’re small, your main concern is backups in the following scenarios:
hard-drive failed etc.
Bug / Security
data maliciously / accidentally wiped
backups poisoned or corrupted.
These problems are solved well enough, for most filesystems. (eg, off-site backup cron-jobs)
When you get a bit bigger you have to worry about:
Server Uptime / Availability
eg, what happens if the machine with that users pictures goes down?
How to share data between lots of servers on separate machines?
eg. Web server hosts ‘users/images/’, but a separate processing server needs to make thumbnails.
If you build your app around fs commands, you’ll need to start adding these things in later, and developing your own solutions. OR, just accept failure, and notify your users of data-loss or downtime, and restrict how your application scales.
If you’re running your service in the cloud, the idea is that no individual machine should really matter. Think of your servers as “cattle” instead of “pets”.
This causes a few problems for standard storage solutions - if you store you’re files on the local disk, losing the machine matters. You’ve just made a “pet”.
Put them on a specialised storage “service”… and you’ve now got “cattle”.
So it goes - Your machines should contain nothing but the latest copy of your source / configuration.
Aside - this is solved for databases (the other type of on-disk storage), by “streaming replication” or similar features.