Discussion: Next-Gen Product Image Management #418

New Issue

2026-06-29T08:38:09Z

rob commented

2026-06-29 08:38:09 +00:00

This ticket is for discussion about image handling. For specification and estimation, see #127.

Open Questions

Question: Do we currently use watermarking any more?

Watermarking isn't terribly hard, but if we're not currently using it, it makes sense to defer implementation so we can focus on the core stuff.

Answer

...

Question: Do we currently use any of the bulk-download options from the product-list page?

Like with watermarking, this is not terribly hard to implement, but would require re-implementation which could be deferred to save time and allow us a chance to rethink it.

Answer

...

Question: How important are eStack branded URLS (ie: https://img.estack.com/rdmobile/102221/product-image.jpg) vs the default s3 URLs (ie: https://estack-images.s3.amazonaws.com/rdmobile/101212/some-image.jpg)?

'estack.com' type URLs are easy to do with s3 for regular HTTP, but HTTPS would require us to do one of two things:

Proxy all requests through our own servers (Browser <==> img.estack.com <==> s3.amazonaws.com). Pros: Pretty darned easy. Cons: If eStack is down for any reason, then nobody can get images. Puts load on our web server that isn't strictly necessary
Set up CloudFront CDN with custom domain and SSL cert. Pros: It's a CDN, which buys us two nice things. Images get served super-fast around the globe, and the image system is super-highly-available. Cons: Need a separate SSL cert.

I prefer the CloudFront setup from a technical perspective. I suspect costs will be single-digit dollars per month, possibly even pennies per month. See pricing here: https://aws.amazon.com/cloudfront/pricing/

That said, we might be able to save some time headache by just using the public S3 URLs by default. They would look something like: https://estack-images.s3.amazonaws.com/rdmobile/101212/some-image.jpg.

Tim's feeling is that we should just use the public s3 URLs for free to K.I.S.S. for now. We can always add CloudFront or our own proxy later if/when we need it.

Answer:

...

This ticket is for discussion about image handling. For specification and estimation, see #127. # Open Questions ## Question: Do we currently use watermarking any more? Watermarking isn't terribly hard, but if we're not currently using it, it makes sense to defer implementation so we can focus on the core stuff. ## Answer ... ## Question: Do we currently use any of the bulk-download options from the product-list page? Like with watermarking, this is not terribly hard to implement, but would require re-implementation which could be deferred to save time and allow us a chance to rethink it. ## Answer ... ## Question: How important are eStack branded URLS (ie: https://img.estack.com/rdmobile/102221/product-image.jpg) vs the default s3 URLs (ie: https://estack-images.s3.amazonaws.com/rdmobile/101212/some-image.jpg)? 'estack.com' type URLs are easy to do with s3 for regular HTTP, but HTTPS would require us to do one of two things: 1. Proxy all requests through our own servers (Browser <==> img.estack.com <==> s3.amazonaws.com). Pros: Pretty darned easy. Cons: If eStack is down for any reason, then nobody can get images. Puts load on our web server that isn't strictly necessary 1. Set up CloudFront CDN with custom domain and SSL cert. Pros: It's a CDN, which buys us two nice things. Images get served super-fast around the globe, and the image system is super-highly-available. Cons: Need a separate SSL cert. I prefer the CloudFront setup from a technical perspective. I suspect costs will be single-digit dollars per month, possibly even pennies per month. See pricing here: https://aws.amazon.com/cloudfront/pricing/ That said, we might be able to save some time headache by just using the public S3 URLs by default. They would look something like: https://estack-images.s3.amazonaws.com/rdmobile/101212/some-image.jpg. Tim's feeling is that we should just use the public s3 URLs for free to K.I.S.S. for now. We can always add CloudFront or our own proxy later if/when we need it. ## Answer: ...

rob added the Discussion label 2026-06-29 08:38:09 +00:00

rob closed this issue

2026-06-29 08:38:09 +00:00

Sign in to join this conversation.

No Label Discussion

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: rob/pms3#418