junohm410
commented
3 weeks ago 📝8/16質門タイムで相談したこと / komagataさんにご回答いただいたことのメモ
写真のファイルサイズを小さくするため、ActiveStorageを使って写真をストレージに初回保存する前にwebpへの変換をかけることを試みたが、以下の問題が直面した。
- 画像のバリデーションとの組み合わせるのが難しい
- 画像を添付 -> バリデーション通過後に
before_saveコールバック内でwebpに変換 -> 再添付 ->saveという流れを試したが、コードの流れがいびつになることに加え、添付を二回行うせいでストレージにファイルが2度アップロードされるという問題が起こり、これを解決できなかった - 実装のイメージは以下の記事に近い形を想定していた
- Resize images before saving them with Ruby on Rails Active Storage - DEV Community
- 画像を添付 -> バリデーション通過後に
ActiveStorageの思想が「まず大元のファイルを保管し、それをもとに加工したバリアントを作って配信する」というものなので、そのレールに乗ることができていないのがいびつさの原因になっているのではという意見をいただく。
- ActiveStorageの敷いた道（と大本のRails way）を行くことを良しとして採用するのであれば、その結果としてストレージに収容する総ファイルサイズは大きくなるのは自然なこと（もちろんケアは必要だが）
- ファイルサイズのケアが要件として重要であれば、ActiveStorage以外の道を行く = 他のgemを使うというのが筋
- もしくはJS側でバリデーションや変換を行うなど
FBCフリマについては小規模な利用者数で使われることを想定しているので、ファイルサイズの問題よりもコードのメンテのしやすさなどのメリットを得られる「ActiveStorageの道 = 保存前に加工はせず、表示シーンに合わせて軽いバリアントを作る」という方向で進めることに決定。
以下はリサイズに関するmachidaさんからのご助言のメモ
実際に見るサイズが 320 ピクセルなら、その倍のサイズがあれば Retina でも見れる 最大でも 2000 ピクセル Hero イメージとかでも
余計なデータを省くことで、ファイルサイズを小さくできる 位置情報を消せるとセキュリティ的にもいい webp という形式に変換すると、軽くなるので調べてみる
ある程度の期間が経ったら消すとか でもこれはアプリの基礎部分を作ってみて確認のほうがいいかも
画像に対して、どれくらいの容量を見込むのか？について いずれにしても見込んで計算しないとわからないし、提案できない iPhone で写真をとって商品をアップすると、一枚あたりどれくらいの容量なのか、というのは確認したほうがいい