6 ms·
This seems unnecessary at first pass. Why not just upload directly to S3 using their REST API and then persist the returned data via GraphQL (if so desired). Am
by ukulele 9y ago
This seems unnecessary at first pass. Why not just upload directly to S3 using their REST API and then persist the returned data via GraphQL (if so desired). Am I missing something?
- EpicEng 9y agoThat was my first thought when I read the headline... API or, hell; just use the CLI directly. Works great, I don't get it. That said, I have no idea what paperclip is and I wouldn't even consider using a framework like rails for such a simple task.
- pmontra 9y agoThe premise of the post is having a Rails application with a User model and the requirement of letting users upload profile pictures to S3. The post should not be much interesting outside Rails development. The question is why doing it by base64 encoding those images through the GraphQL API, but not all tutorials show useful examples. BTW, paperclip is a gem that allows to add files to a model, with extensions to handle several backends (S3 among them) and process those files (convert formats, crop images with frontend integration, etc). It's probably the oldest gem in that genre, the main alternative being Carrierwave.
- EpicEng 9y agoYeah that's fair, I should have... read the article.
- kamikaz1k 9y agoI think the OP is simply trying to do a How-To File Upload with GraphQL article, the S3 is secondary. Alternatively, if you needed to allow some user to upload files, you might want to guard against abuse and generate expiring links.
- aaronbwebber 9y agoYES. This is basically proxying to S3. Why would you ever want to do that? You want to give clients a presigned URL to do the upload. Lots of ORMs support "file fields" though which encourage you to do this or something similar.
- deleted 9y ago[deleted]
- mengledowl 9y agoOP here. There are a few reasons you might want uploads to go through the server, and they basically amount to having more control. Imagine that you have an API that's being used by multiple sources - maybe a web app and a mobile app. The initial work to create uploads to S3 directly for each might not be too bad, but what happens if you want to change something later? Maybe you decide to move from S3 to something else, or maybe you decide that each upload should actually generate 3 different sizes of the image. If you do it through the server, this is all relatively simple. On the other hand, if you do it directly to S3, then not only do you have to change it in two places now, but you also have to navigate the issue of app versions - your original app version is uploading to S3 but your new one is uploading to some other hosting service, so how do you really get off of S3? And how do you keep them in sync? Definitely possible, but much more painful than changing a few configuration options on the server and migrating the existing data, etc.
- hartator 9y agoI think you are mistaken. Currently best way to handle images for user is to upload directly to S3 via JS -> Save the S3 id to db -> Resize on the fly via aws lambda.
- andreime 9y agoNot an expert on this. This doesn't seem secure. How are you confident you don't allow people to misuse your s3 bucket?
- aaronds 9y agoThe S3 SDK allows you to generate a URL that can only be used to upload to a specific path (+ there are other constraints you can enforce, file size / mime type etc)
- eknkc 9y agoYou create a policy [1] for each upload and sign it. The users browser has to provide the policy which can set the path (or prefix), limit file size etc. [1]: http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-HTTPPOSTConstructPolicy.html http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-HTTPPOS...