Meteor 1.3. write to public folder

help
1

I am writing an application where I can upload images. Eventually I’ll upload them to some external service like s3, but for the moment I want to upload them to the filesystem where the meteor server is running.
The idea is to write them to some subfolders of the ‘public’ folder so that they can be displayed in the client easily.
Example the client could go to /products/.jpg and see the image of that product.

I first tried using packages for that but after looking for a long time I didn’t find any that were not deprecated, still actively maintained, and working fine with meteor 1.3 and/or react, so I decided to do it manually.

I got the client upload working, the server has a method that uses Node’s FS to actually write the file and it works fine. The problem is that the file gets saved in .meteor/local/build/programs/server directory by default.

My questions are:
1)How do i obtain the filepath to the project root and/or public folder so I can write there?
2)Is there a reason why I shouldn’t do it this way and be obliged to use something else (like mongo’s gridFS for example?)
3)Any other suggestions?

2

Here’s how you obtain the path to /public using relative paths:

const fs = require('fs');

var path = process.env['METEOR_SHELL_DIR'] + '/../../../public';

fs.writeFile(path + "/" + filename, blob, encoding, Meteor.bindEnvironment(function (err) {
    if (err) {
        console.log("Error:" + err);
    } else {
        console.log("Success");
    }
}));

Though I’m using a static path in production, outside the actual meteor environment. I’m using nginx as a proxy to handle SSL and am thus also speeding up handling those files by telling nginx to pass everything under http://meteorapp.com/static to said static folder directly. Everything else gets handled by the meteor app.

2 Likes
3

thanks. I actually considered the ‘relative’ path solution but it looked dirty so I looked for something else.

I ended up saving to a folder outside of meteor and having a local nginx serving the files for me since anyway it’s the better approach until I don’t go with a proper cloud/cdn approach.

thanks anyway!

4

Yes, I’m doing that as well. For development I’m using the relative path, though. Makes things a bit easier, configurationwise.