【开发笔记】我的云端相簿

有人说“摄影穷三代，音响毁一生“。姑且不论实际如何，玩摄影荷包扒层皮是免不了的，如今连找个网路相簿储存也通通都是钱啊😱

相簿开始收费以后

早期底片相机的时代，拍照其实是很费时耗力的事情。除了初期设备上的一次性投入，每次拍完照片的底片冲洗，也都是长期性的持续消耗。然而，就算是来到数位相机时代的今天，也不尽然事事都能恣意地放飞自我。随着相片数量的快速累积，云端储存终究会跨过免费的门槛，成为付费会员终究是早晚必须面对的选择。

云端相簿的选择众多，但是我要的功能却是

自然在 2022 年的今天，网路相簿不但是非常普通的服务，而且选择众多。不过图片的管理与移转都是相当麻烦的一件事情，所以相簿一但选定了之后，就不要轻易地转移或更换。因此，固然收费方案需要斟酌考虑，其他附加的功能也不能轻忽。

总结了以下，根据自己的使用需求，云端相簿基本该具备的特色至少如下：

• 相对宽松的照片上传限制，例如：可以储存拍摄时的原始档案，并且没有数量上的限制。
• 原始档案虽然上传到云端，但是非拥有者无法轻易访问取得。
• 系统除了储存用途，同时还必须能够解析 EXIF 资讯。
• 原始档案一但储存之后，实时同步缩放成不同尺寸的解析度。
• 基于隐私的考量，缩图去除 EXIF 讯息。
• 缩图可以连结作为第三方嵌入与分享使用。
• 缩图经由 CDN 分布，并使用 SSL 传输。
• 支持自订域名。

不过事情没有憨人想得那么简单

大概是想得太单纯了，也或许自己的需求太过小众。总之寻找合用的云端相簿似乎不是那么容易。特别还要能够支持第三方网页嵌入的是个问题，更遑论搭配个人自订域名来使用。几番思量，既然现成合用的没有，不如就自己开发一个吧。特别是手上定额付费 AWS 的闲置资源还有，基于实惠的考量，其实多多利用才是上策。反正相机才刚买，照片也还照得不多，或许这个时间点着手开发订制化的相簿正是时机。

所以大概有这些工作需要着手

既然决定要把手上 AWS 闲置的资源动起来，目前决定采取的架构方案如下：

• 双 Bucket 配置，将原始档案与不过大小的缩图储存分离开来。并且各自分配合适的 ACL 权限管理。
• 原始档案上传后，PUT 物件的事件会触发 Lambda 无伺服器服务，进行不同尺寸的缩图处理并且转存另一处 Bucket。
• 缩图采用 webp 格式，且去除内嵌的 EXIF 讯息。
• 上传动作的执行透过基于用户登入的管理页面来操作。
• 管理系统包含基本的相簿创建编辑，以及照片的上传与删除。
• 并且管理系统产生的数据，同时是基于用户权限的访问许可来管理。
• 原始档案一但删除，相关联的缩图也会一并同步删除，以利空间最大化的运用。
• 以 Cloudfront 配置 CDN，并与自订域名做连结。
• 所有的操作与传输动作仅限以 HTTPS 存取访问。

千里之行始于足下

洋洋洒洒写了这么些，看来待实践的工作还真不少。不过空想是不会有结果的，如果这篇看来像废文的笔记还有后续，那还真是可喜可贺可喜可贺（笑）。