In Rails 5.2, Active Storage gives us the ability to generate permanent urls that are redirecting to an asset, via unique signed urls at each call.
html:
<img src='/rails/active_storage/blobs/ey...' />
server:
Started GET "/rails/active_storage/blobs/eyJfcmFpbH...
302 Redirected to https://bucket.amazon/image.jpg?X-Amz-Algorithm=AWS4-HMA...
I am wondering about the number of HTTP requests Active Storage is adding to the monolith, one blob_url in the web page = one additional request to the monolith, in order to get the final asset url via 302 redirect. So One page with 20 images => 20 additional requests. (but they are pretty fast)
So my question is : why using this system instead of using the final URL directly (.service_url
) :
<img src='https://bucket.amazon/image.jpg?X-Amz-Algo...'>
?
I am thinking of these arguments : (but is there any other?)
The out-of-the-box behavior of Active Storage is to generate URLs which point back to the Rails application. When accessed, these URLs redirect to the actual service endpoint for the file.
This does increase the number of requests to the Rails app server since all file access needs to go through there.
Having the Rails app in between the user and the files provides several benefits (some of which are mentioned in the OP):
From the Active Storage guide:
This indirection decouples the public URL from the actual one, and allows, for example, mirroring attachments in different services for high-availability.
For more discussion about the pros/cons of abstracting away file access through the Active Storage Service API, check out this thread:
https://github.com/rails/rails/issues/31419
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With