Request based prefix

[mohanklein]

https://github.com/janko-m/uppy-s3_multipart/blob/3bbe43e40422471d5923f9a141761a7bdaa7ddd6/lib/uppy/s3_multipart/app.rb#L29

Hi! I am tryin to add an additional request based prefix to uploads. Not a general one which can be mounted via prefix in constructor already. If we added plugin :request_headers one could do something like this:

UPPY_S3_MULTIPART_APP = Uppy::S3Multipart::App.new(bucket: bucket, public: true, prefix: 'general_prefix_like_my_new_app', options: {
  create_multipart_upload: -> (request) {
    key = request.headers["custom_prefix"] || '' # e.g. 'avatars'
    key << SecureRandom.hex
    key = "#{opts[:prefix]}/#{key}" if opts[:prefix]
    {
      key: key
    }
  }
})

I can't find a way to save data in a clean way inside a single bucket. most apps will have multiple uploads in different business scopes, e.g. 'avatars' and 'car-images'.

[mohanklein]

@janko-m updated comment to request.headers["custom_prefix"] :-)

[jrochkind]

It's possible it would be useful to have a way to do this with this gem, I'm not totally sure. But I want to interrogate the use case just a bit.

Curious if you're using shrine?

most apps will have multiple uploads in different business scopes, e.g. 'avatars' and 'car-images'.

When used with shrine, uppy-s3_multipart ends up being used to send a file to shrine's configured "cache" storage. It will later be copied over to "store" storage, when made "permanent".

Personally, I haven't seen a need to segregate "different business scopes" in "cache" storage, although I do in "store" storage.

[janko]

@mohanklein Note that you can already retrieve HTTP headers without the request_headers Roda plugin:

request.env["HTTP_CUSTOM_PREFIX"]

I know it's not as pretty as request.headers["Custom-Prefix"], but I would ideally not like to couple uppy-s3_multipart to Roda, so that in the future it can theoretically be replaced with another Rack-based web framework (however unlikely that may be, Roda is awesome). Also, at the moment I don't think it's worthwhile loading additional code from the request_headers plugin for everyone, because probably only a handful of users will use it.

[mohanklein]

seems like the use case isn't really there for most people :-) thanks anyways guys!