FirebaseのImageの保存においては、サーバーでリサイズしなくて良いのではないか。

Question

FirebaseのStorageのruleを使う限りでは、
画像を保存する際に、フロント側でクロッピング(トリミングやリサイズのこと)をすれば、
それ用のサーバーを設けなくても同様のことができるのではないか。

Firebaseを使っていても、画像のresizeはgoogle clond functionを使っている例がネットで多く見られ、気になったので
投稿いたしました。

よろしくお願い致します。

Answer 1

FirebaseのStorageのruleを使う限りでは、
画像を保存する際に、フロント側でクロッピング(トリミングやリサイズのこと)をすれば、
それ用のサーバーを設けなくても同様のことができるのではないか。

Firebaseを使っていても、画像のresizeはgoogle clond functionを使っている例がネットで多く見られ、気になった

できる/できないで言うと、もちろんフロント側でも同様のことができます。
ただ画像処理は、比較的リソースを大量に必要とするので、それをフロントだけで行うよりも、可能な限り負荷分散して非同期的に処理（Firebaseにお任せ）するのがUX的に好ましいからです。
これはFirebase公式でもユースケースとして紹介されています。
https://firebase.google.com/docs/functions/use-cases?hl=ja#execute_intensive_tasks_in_the_cloud_instead_of_in_your_app

その場合「もととなる画像」さえFirebaseにアップロードされていれば、非同期でリサイズ等の処理が失敗したとしても、その画像をもとに、何度でもFirebase側だけで（フロント側にほとんど影響なく）リトライが可能とういうメリットもあります。

Comments

[kaggle]

ご返信ありがとうございます。
プロフィール画像とかのuploadの場合、cropperjsなどを使って、ユーザーが自分の顔だけを切り取って、トリミングさせる場合も、残りの処理であるリサイズに関しは、Clound Functionsに任せた方が良いでしょうか。
firebaseのruleでuploadされる画像のsizeを制御できるという認識を持っており、そうであるならば、このケースでは、サーバーでリサイズするメリットが分からなくなりました。(cropper.jsを使うと、顔の切り取りであるトリミングと同時に、サイズも制御できるから)
cropper.jsを通した、プロフィールの顔のuploadでは、サーバーを用意するメリットがあまりないと考えています。
いかがお考えますでしょうか。
よろしくお願い致します。
https://fengyuanchen.github.io/cropperjs/

[xenbeat]

> ユーザーが自分の顔だけを切り取って、トリミングさせる場合も、残りの処理であるリサイズに関しは、Clound Functionsに任せた方が良いでしょうか。

> cropper.jsを通した、プロフィールの顔のuploadでは、サーバーを用意するメリットがあまりないと考えています。いかがお考えますでしょうか。

まず、サーバーを用意（Firebaseにお任せ）するメリットは回答でもお伝えした通りです。

Firebaseにお任せするかの判断ポイントは、クライアント端末での処理が「要件として」現実的かどうかです。
ゆえにこの手の質問には一般解はなく、サポートする端末およびその想定スペック、レスポンスタイム、画像の管理方法等のアプリ開発要件によって判断することになります。

それが前提となりますが、
こちらのケースに関しては、クライアント側でトリミング、リサイズをやってしまうのもありだとは思います。
とりあえずやってみて、やっぱオリジナル画像は残しておきたい、複数のサムネイルを生成したい、クライアントの負荷をもうちょっと軽減したい等の状況になってから、Clound Functionsの利用を検討するというのも良いでしょう。

[kaggle]

納得できました。
ひと昔と違って、多く人が十分なスペックの端末を持っていると考えているので、
まず、クライアント側でやってみて、不足があれば、Clound Functionsの利用を検討という方針で行っていこうと思います。
ありがとうございました。

Answer 2

その発想はなかった……天才ですね。
単純に使われていないのはJavaScriptというスクリプト言語が
Cの1/20程度のパフォーマンスしか出ないって所に原因があるように思えます。

最近のノートパソコンやデスクトップならいざしらず、
スマホユーザーがローカルで画像をクロッピングして、元画像に添えてアップロードをし始めたらブチギレでしょうね。
画像の二重アップロードとサムネイル画像生成はユーザに押し付けるにはちと業が深いと思います。

コインハイブも、ぶっちゃけ広告収入の方がマシみたいな金にしかなってないみたいですし。
期待のWebAssemblyが流行っても名前ほどのパフォーマンスは出ません。

---

ちなみにJavaScriptで出来る事を増やすってのは、
「改ざん可能な領域を拡張する」のと同義です。
もともとは画像1個だけ見張っていれば良かったものを、サムネイル画像と本物の画像が両方妥当かを見張る必要が出てきます。

例えば単純所持違法化された児童ポルノ系の画像を、
サムネイル画像として差し替えられてたら取り除かないといけませんよね？
その作業が漏れていたらサービスとして致命的な事になりませんかね？っていう感じです。

この辺を正しく理解しつつ図を描き、
ユーザに背負わせた分は、その分サービス使用料から割り引く等で還元出来れば良いんじゃないかなと思います。