3 ms·

Lots of good stuff here, but I do wonder if some of the default behaviour is getting a little too magical: When you use new Response(s3.file(...)), instead of

Lots of good stuff here, but I do wonder if some of the default behaviour is getting a little too magical: When you use new Response(s3.file(...)), instead of downloading the S3 file to your server and sending it back to the user, Bun redirects the user to the presigned URL for the S3 file. That's a rather surprising choice for the default, and it's not at all obvious how you'd disable it if you don't want to expose your S3 bucket directly.

hombre_fatal 2y ago
Pass a stream into the response. Response(file.stream())
- mort96 2y ago
  I mean thanks but that doesn't change the fact that > That's a rather surprising choice for the default, and it's not at all obvious how you'd disable it if you don't want to expose your S3 bucket directly.
  - iainmerrick 2y ago
    To be fair, it does answer my “not at all obvious” bit -- just calling stream() is pretty clear! I should have thought a little longer.
adam_arthur 2y ago
I respect the area Bun is trying to carve out, but if you follow the creator on Twitter, you'll see the decision making process is very focused on short-term wins/convenience and very light on the deeper implications of the "magic" I was initially excited about the project, but have no faith in the long term direction given the spurious (and often poor IMO) design decisions. At least as it's publicized on socials. It would have been fine if they kept it v0.x, but releasing 1.0 should have significantly raised the bar for increasing API surface area
steve_adams_86 2y ago
I don't like this design, thought I get why they did it. Personally I think this is very 'side effecty', and it reads like you'd be returning the file contents and not a URL. Even so, what would bother you about exposing the bucket? It's also a presigned URL so it doesn't have broad access utility. I'd prefer an API like this where it's explicit: Response((file(...).getPresignedURL())) Alternatively, the option to set an env variable or bun config which turns this behaviour on
- iainmerrick 2y ago
  What would bother you about exposing the bucket? There's no immediate security hole, but I'd still be wary about exposing the bucket name, directory name and object name unnecessarily. Those might have a direct correspondence with the original public URL, but they might not. Maybe the object name is a database ID and the same ID gets used elsewhere for some other purpose. Who knows? Why take the chance if you don't need to? I'd prefer an API like this where it's explicit That's the thing, in the previous section it already described the "s3.presign()" function. If you want to redirect to a presigned URL, you already have everything you need, no magic required.
  - steve_adams_86 2y ago
    I missed the presign method. It would be very concise to be explicit here. The more I look at recent bun developments the more it seems like they’re shooting for magic rather than intelligent design. It’s clearly impressive stuff and I’m glad they’re doing what they’re doing, but stuff like this makes it so I’m hesitant to commit to the runtime APIs.

hombre_fatal 2y ago

Pass a stream into the response. Response(file.stream())

mort96 2y ago
I mean thanks but that doesn't change the fact that > That's a rather surprising choice for the default, and it's not at all obvious how you'd disable it if you don't want to expose your S3 bucket directly.
- iainmerrick 2y ago
  To be fair, it does answer my “not at all obvious” bit -- just calling stream() is pretty clear! I should have thought a little longer.

adam_arthur 2y ago

I respect the area Bun is trying to carve out, but if you follow the creator on Twitter, you'll see the decision making process is very focused on short-term wins/convenience and very light on the deeper implications of the "magic" I was initially excited about the project, but have no faith in the long term direction given the spurious (and often poor IMO) design decisions. At least as it's publicized on socials. It would have been fine if they kept it v0.x, but releasing 1.0 should have significantly raised the bar for increasing API surface area

steve_adams_86 2y ago

I don't like this design, thought I get why they did it. Personally I think this is very 'side effecty', and it reads like you'd be returning the file contents and not a URL. Even so, what would bother you about exposing the bucket? It's also a presigned URL so it doesn't have broad access utility. I'd prefer an API like this where it's explicit: Response((file(...).getPresignedURL())) Alternatively, the option to set an env variable or bun config which turns this behaviour on

iainmerrick 2y ago
What would bother you about exposing the bucket? There's no immediate security hole, but I'd still be wary about exposing the bucket name, directory name and object name unnecessarily. Those might have a direct correspondence with the original public URL, but they might not. Maybe the object name is a database ID and the same ID gets used elsewhere for some other purpose. Who knows? Why take the chance if you don't need to? I'd prefer an API like this where it's explicit That's the thing, in the previous section it already described the "s3.presign()" function. If you want to redirect to a presigned URL, you already have everything you need, no magic required.
- steve_adams_86 2y ago
  I missed the presign method. It would be very concise to be explicit here. The more I look at recent bun developments the more it seems like they’re shooting for magic rather than intelligent design. It’s clearly impressive stuff and I’m glad they’re doing what they’re doing, but stuff like this makes it so I’m hesitant to commit to the runtime APIs.