【開發筆記】我的雲端相簿

有人說“攝影窮三代，音響毀一生“。姑且不論實際如何，玩攝影荷包扒層皮是免不了的，如今連找個網路相簿儲存也通通都是錢啊😱

相簿開始收費以後

早期底片相機的時代，拍照其實是很費時耗力的事情。除了初期設備上的一次性投入，每次拍完照片的底片沖洗，也都是長期性的持續消耗。然而，就算是來到數位相機時代的今天，也不盡然事事都能恣意地放飛自我。隨著相片數量的快速累積，雲端儲存終究會跨過免費的門檻，成為付費會員終究是早晚必須面對的選擇。

雲端相簿的選擇眾多，但是我要的功能卻是

自然在 2022 年的今天，網路相簿不但是非常普通的服務，而且選擇眾多。不過圖片的管理與移轉都是相當麻煩的一件事情，所以相簿一但選定了之後，就不要輕易地轉移或更換。因此，固然收費方案需要斟酌考慮，其他附加的功能也不能輕忽。

總結了以下，根據自己的使用需求，雲端相簿基本該具備的特色至少如下：

• 相對寬鬆的照片上傳限制，例如：可以儲存拍攝時的原始檔案，並且沒有數量上的限制。
• 原始檔案雖然上傳到雲端，但是非擁有者無法輕易訪問取得。
• 系統除了儲存用途，同時還必須能夠解析 EXIF 資訊。
• 原始檔案一但儲存之後，實時同步縮放成不同尺寸的解析度。
• 基於隱私的考量，縮圖去除 EXIF 訊息。
• 縮圖可以連結作為第三方嵌入與分享使用。
• 縮圖經由 CDN 分佈，並使用 SSL 傳輸。
• 支持自訂域名。

不過事情沒有憨人想得那麼簡單

大概是想得太單純了，也或許自己的需求太過小眾。總之尋找合用的雲端相簿似乎不是那麼容易。特別還要能夠支持第三方網頁嵌入的是個問題，更遑論搭配個人自訂域名來使用。幾番思量，既然現成合用的沒有，不如就自己開發一個吧。特別是手上定額付費 AWS 的閒置資源還有，基於實惠的考量，其實多多利用才是上策。反正相機才剛買，照片也還照得不多，或許這個時間點著手開發訂製化的相簿正是時機。

所以大概有這些工作需要著手

既然決定要把手上 AWS 閒置的資源動起來，目前決定採取的架構方案如下：

• 雙 Bucket 配置，將原始檔案與不過大小的縮圖儲存分離開來。並且各自分配合適的 ACL 權限管理。
• 原始檔案上傳後，PUT 物件的事件會觸發 Lambda 無伺服器服務，進行不同尺寸的縮圖處理並且轉存另一處 Bucket。
• 縮圖採用 webp 格式，且去除內嵌的 EXIF 訊息。
• 上傳動作的執行透過基於用戶登入的管理頁面來操作。
• 管理系統包含基本的相簿創建編輯，以及照片的上傳與刪除。
• 並且管理系統產生的數據，同時是基於用戶權限的訪問許可來管理。
• 原始檔案一但刪除，相關聯的縮圖也會一併同步刪除，以利空間最大化的運用。
• 以 Cloudfront 配置 CDN，並與自訂域名做連結。
• 所有的操作與傳輸動作僅限以 HTTPS 存取訪問。

千里之行始於足下

洋洋灑灑寫了這麼些，看來待實踐的工作還真不少。不過空想是不會有結果的，如果這篇看來像廢文的筆記還有後續，那還真是可喜可賀可喜可賀（笑）。