Dropbox は古くはローカルファイルシステムの同期から始まり、ファイル共有機能、Dropbox Paper を使ったドキュメント共有・管理、Dropbox Passwords といった 1passwords 的なものまで、様々なソリューションを提供している。

ファイルシステムは古くから使われていて、原始的だけど様々な方法で活用できる。たとえば、この文章は VSCode で markdown として書いているのだけど、保存先は Dropbox で同期しているファイルシステムで書いている。markdown のヘッダに追加している YAMLのメタデータが publish な記事が更新されたら、これまた Dropbox と同期している Linux サーバ上でファイルの mtime の更新を検知し、サイト用の静的ファイルがビルドされデプロイされる。

ファイルシステムを同期する、以外のふつうの http で叩ける Dropbox APIも用意されている。この Dropbox API をざっくり使ってみた感じ結構よくできていて、OAuth2 認証で手元のプログラムはもちろん、Web 上では自分のサーバサイドプログラムを経由せずとも認証が行なえ操作が行える。

つまり、Web 上のエディタで、Dropbox 上に置いた markdown を編集して保存なんかもできる。また、古き懐かし longpoll を使ってファイル更新検知なんかもできる。

このWebサイトの記事も、Windows 上の VSCode 上で書いて、実際のサイト上でどうレンダリングされ表示されるかは、これらの API を使って実際に secon.dev のWebサイト上でリアルタイムプレビュー表示している。VSCode で保存したら、ファイル更新が検知され、ブラウザ上で自動更新されるので、とりわけ写真が多い記事で便利に使っている。公開時には makrdown につけてる YAML の publish を true にして保存すればビルドが走る。

話は変わって、Google Photos 無料化が終わってしまうため、次の画像ホスティング先を検討している中で、Dropbox は月額1200円(年間契約の場合)で2TB。それなりに画像をアップロードしても、自分の用途では数年は十分(raw は Adobo Cloud Storage に Lightroom 経由でアップロードしてるし)持ちそうだ。誤ったファイル削除をしてしてしまっても、簡単に復元ができる。

画像のアップロードは、スマートフォンからは Dropbox アプリで写真を自動アップロードすればよく、PC からは Lightroom の現像書き出し先を Dropbox のファイルシステムにすれば、明示的にアップロードをしなくても勝手にアップロードされる。

Web からの Dropbox のファイルシステム上の画像は、共有リンクを取得しないと web からの直接アクセスはできないのだけど、共用リンクのクエリパラメータに ?raw=1 をつけることで、適切な Content-Type で返却してくれるので、自分のサイトから直リンができる。画像のサムネイルを Web から直接アクセスできる API は無い(欲しい...)のだけど、リサイズ後のバイナリデータを直接返す API はあるし、自前のファイルシステム上でリサイズ実行しても良いし、画像リサイズするような proxy サーバを挟んでも良いし、Dropbox のファイル変更通知の webhooks をトリガーにリサイズ画像を作る AWS API Gateway や GCP の Cloud Function なんかを作っても良いだろう。

まだ Dropbox を Google Photos の代替にしたわけではないのだけど、選択肢の一つとしてはアリなように思える。引き続き、2020年6月になる前に、自分にあったベストな管理方法を選びたい。

そんな感じで、古き良き Filesystem の同期サービスとしてそのまま使うこともできるし、Web ブラウザ + OAuth 認証で API を使うこともできる Dropbox、結構使い所がありそうで最近見直しているところ。