Exploring Storage Strategy — Presigned URLs, Tigris CDN, and More

[nichtsam]

I've been implementing EpicStack's storage logic onto my personal project, and I've been working on some optimizations.
Since it could involve significant changes, I’d like some insights and feedback before opening a PR for this.

This is the link to my current implementation:
https://github.com/nichtsam/nichtsam.com/tree/dev/app/utils/storage

Discussion Points

1. Switching to presigned URLs instead of Authorization headers
   This approach opens up more flexibility — including the potential to use Tigris as a CDN.
2. Using virtual-hosted style URLs
   This is encouraged by both Tigris and S3. Could help with compatibility and future-proofing:
   https://www.tigrisdata.com/blog/virtual-hosted-urls/
   https://docs.aws.amazon.com/AmazonS3/latest/userguide/VirtualHosting.html#path-style-access
3. Support for object deletion
   Simple but useful
4. Not going with chunked upload (aws-chunked / streaming)
   HTTPS already offers decent security, and the extra complexity doesn’t seem worth the marginal benefit.
5. Staying away from AWS SDK?
   Currently, there’s no S3 client used. I’m guessing it’s to stay dependency-free and more agnostic?
6. Potential idea: use Tigris as a CDN cache for openimg
   We could make openimg no-cache and implement logic to cache via Tigris, benefiting from their CDN layer.

[kentcdodds]

@andrelandgraf what do you think about some of these ideas that involve openimg?

[andrelandgraf]

Potential idea: use Tigris as a CDN cache for openimg

Not sure how this would look like with Tigris, but adding a CDN in front of the web server for static files and optimized images would probably increase response times and reduce the load for the web server (if that's the concerns) but I know there are some caveats with CDNs and Fly.

[nichtsam]

Potential idea: use Tigris as a CDN cache for openimg

Not sure how this would look like with Tigris, but adding a CDN in front of the web server for static files and optimized images would probably increase response times and reduce the load for the web server (if that's the concerns) but I know there are some caveats with CDNs and Fly.

Just to confirm — when you say "increase response times", do you mean it would reduce latency or actually add latency?

[andrelandgraf]

Reduce/improve response time* 😅

CDNs are much faster at serving files than general-purpose web servers and usually closer to the user as well. This should result in reduced response times!

With Fly, you can already be globally distributed and close to the user, so it may not make a big difference, but if you want to avoid a local file cache then caching via a CDN would probably be a good next step.

[nichtsam]

I integrated openimg into my site today and experimented with using Tigris as a cache layer.
It’s more of a rough draft than a proper implementation — not fully thought through — but the added latency seems to be a dealbreaker for now.

Code’s here if anyone’s curious:
https://github.com/nichtsam/nichtsam.com/blob/openimg/app/routes/resources%2B/tigris-cached-images.tsx

[andrelandgraf]

Yeah, using Tigris as a caching layer seems suboptimal because of the added roundtrips. The local filesystem cache for openimg should get you pretty far (especially with HTTP caching). For better performance and scalability, I would look into adding a dedicated CDN in front of the openimg endpoint/web server.

[nichtsam]

Thanks for confirming!