No prob, so the usecase is such
- user wants to upload file
- file with backend client goes client → POST fat binary → backend → s3 (this is kinda inefficient especially since the destination is actually s3 not the server)
- instead client → POST get presigned url → client uploads binary direct to s3 (skipping the network and overhead of having to upload the file 2x once to the server and the server again to s3 double network traffic
- its very common in most places where a javascript frontend is used (https://medium.com/@aakashbanerjee/upload-files-to-amazon-s3-from-the-browser-using-pre-signed-urls-4602a9a90eb5 Upload direct to S3 with Pre-signed POST request - BigBinary Blog many resources on this topic)
the store provider would then provide all the “normal” interfaces so that data can be moved from DB and File to S3 but… AS WELL AS and endpoint to calculate the presigned url (ive already laid the basis for this n my PR) the web client would POST request a presigned url and then upload direct to s3 instead of via the server backend (saving bandwith and time)
- no business logic in the front end - client selects file as normal; and on change a presigned url is requested from backend. client then transfers data straight to s3 using the presigned url and extra fields provided by the presigned endpoint
- as with current the incoming request provides things like filename, guessed content type and can be prefixed with random sha as is currently done
- Uploading from Rails to AWS S3 with PreSigned URLs - Stuff… And Things… is also pretty common in the rails world from what i remember