Direct File Uploads to S3: Part 1 Discussion

I would still recommend setting your domain explicitly. You can use in it to specify a wildcard subdomain so you can handle all of those.

From their docs:

In the AllowedOrigin element you specify the origins that you want to allow cross-domain requests from, for example, http://www.example.com. The origin string can contain at most one * wildcard character, such as http://.example.com. You can optionally specify * as the origin to enable all the origins to send cross-origin requests. You can also specify https to enable only secure origins.

AWS docs are some of the worst. Plus every little thing has it's own acronym which makes it even tougher to sift through!

Shrine has a distinction of temporary and permanent storage, and you can use any kind of storage for both. Direct S3 uploads just means that you're using S3 for caching files. So if you're already permanently storing your files on S3 with CarrierWave, adding direct uploads is just an addition, you wouldn't need to reupload any of your existing files (they are already permanently stored).

I listed here the main benefits of using direct S3 uploads. Even if you would like to ultimately store your files on the filesystem, with Shrine you can still upload files directly to S3, and then they will just be downloaded to filesystem on the server-side. This reduces the load on your server, because it doesn't need to accept file uploads. That's probably a rarer use case, but I just wanted to illustrate what do direct S3 uploads mean.

Like Janko said, you can do uploads to your server or to S3 with Shrine just like you would with Carrierwave. Shrine can do everything you could do in Carrierwave (and better in my opinion) so I would recommend using it for everything.

My recommendation would be to never setup your files to upload to your server's filesystem unless it's a hobby project. You'd have to migrate the files once your harddrive is full and that's no fun.

With S3, you have two options:

1. You can upload your files to your Rails server and Shrine will send them over to S3.
2. You can directly upload files to S3 like I showed in this video.

The first option is simpler because you just have to configure Shrine to do the upload to S3.

Direct uploads use your user's browser to upload straight to S3 and it skips your server. That means the direct uploads are faster, but they're a fair amount more work (like you see in the video).

The simplest and best option to get started is to simply use S3 (#1) for both the cache and store for Shrine. You don't have to build any of the Javascript stuff right away and all your uploads will be saved to S3. When you're ready, you can add in the Javascript portion for direct uploads in order to make them upload faster. Since you'd already be using S3, it's a simple change this way.

Allright thank you guys. That helps. Also, for resizing the pictures once they are displayed on a user's profile for example, they should be resized at the processing phase I would believe? or just through a css styling implemented to where they are displayed? Thanks again.

So Heroku won't actually allow you to store files permanently on their servers. You are required to use an external storage service like S3.

If you deployed to Digital Ocean, you can store files since you control the server. Migration isn't the worst, but it can take some time. If you plan on people uploading a lot of files, it's probably worth just using S3 from the beginning.

In either case, I guess I would say you might as well just use S3 from storage from the beginning if you plan to using S3 later.

PutObjectAcl lets you change the ACL of an object in S3. This may not be required, but it's useful if you want to change permissions on files ever like making them public or private. http://docs.aws.amazon.com/...