UGCに関して「一般ユーザーによって作れられたコンテンツ」くらいの理解しかありませんがご了承ください。
【徹底解説】UGCとは何か、なぜマーケティングで重要になってきたのか
サムネイル画像の読み込み先URLはDBにstringとして入っている
assetsに含まれる画像は、Webサイトを必要最低限作るのに必要なものだけ含まれているはずです。
なのでデータベースに問い合わせなくても利用シーンに応じて全てを適切に取り出せるべきです。
これが気持ち悪さの正体ですね。
更に言語化していきます。
サムネイル画像は「利用者が作ったコンテンツ」に内包されるものでしょう。
(Hugoのように開発者が先に作るものならまた話は変わってきますが)
開発環境を構築する場合、本番環境のデータベースと紐付けると何が起こるかわからないので、
ローカル上ではまた別のものを作って作業すると考えられます。
その時、サムネイル画像のURLはローカルのデータベース内に無いですよね?
作ったコンテンツが一切無いのに、assets内にサムネイル画像だけがデブリ(宇宙ゴミ)のように残り続ける。
これは明らかに不要なファイルです。
もっと別管理する良い方法はないかと思案しています。
まぁ既存の流れを汲むのであれば、
リポジトリを分けて、Railsプロジェクトからサムネイル画像だけを叩き出す。
これだけでプロジェクトの品質はぐっと良くなるでしょう。
でも、静的ファイルの配信用ディレクトリが2つ以上になりますよね?
困るんじゃないかと思ってリバースプロキシを構築する案を提案します。
なんのことはない、80番ポートに高速な静的ファイル配信用のWebサーバを用意して、
4000番ポート等の公開しないポートでRailsサーバを構築するだけです。
リバースプロキシとしてよく使われるのはnginxです。
例えば/thumbnail/*
というパス配下の指定をされた場合、
nginxはサムネイル画像があるフォルダの配下を直で探して返す設定にしましょう。
Docker Composeを使えばdocker-compose.yml
1ファイルに数行書き足して、
nginxの設定ファイル1個読み込ませてdocker-compose up -d
コマンド一撃で終わりです。
準備は大変でしょうけど、環境構築さえ終わってしまえば既存の作業量からあまり変わらないはずです。
一般的で言えば、オブジェクトストレージを使った方が良いでしょうね。
サムネイル画像をGit管理しよう!という発想に至ったのは、
「ユーザーが登録した画像が消える」事が怖いからですよね?
ならファイルがあることを保証してくれるサービスを利用すれば良いと思います。
有名どころとしてはAmazon S3とかいかがでしょう?
これはインターネット上にHDDを持てるサービスで中々堅牢です。
CDNで高速に配信したり、WebAPI越しにRubyからファイルの出し入れが出来たりしますので、
アイデア次第で普通にファイルに保存する感覚であれこれ使えるはずです。
ローカルで開発時ではminioみたいなクローンソフトがあり、余計な課金を避けられます。
開発者はDocker等でminioのサーバを立ち上げ、
利用者用の画面から登録した画像や、それを元に生成したサムネイル等のファイルを保管すると良いでしょう。
オブジェクトストレージというサービスでは色々と選択肢はありますので、
競合他社を含めて検討してみてはどうでしょうか?
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2020/09/15 02:39