gemをあんまり追加しないで、Railsアプリをつくる
おれ最近Rails 8でアプリ作ったんやけどさ、そのアプリ作る前に「いまRailsでアプリ作るんやったら、gemあんま追加せんでええで」っていう以下の記事を読んでん。
そんでもってこの記事って、Railsを生んだDHHを擁してる37signalsの人が書いてるやんか。
いわばRailsが公式で「gemあんま追加せんでええ」って言うてる側面もあると思うねん。
で、その思想で結構いい感じにアプリ作れてん。
ってことで、「アプリ作るんやったら大体この機能実装するし、それgem使って実装するやんな」っていうのを、gemを追加せずに実装する方法をまとめた記事やねんこれ。
おれのアプリのコードを載せる用に書き換えるのがめんどいんで、おれアプリコードは載せんけど、処理の流れとか「これ通りにやればできるで」みたいなページのリンクは書いてくわ。
要件を明確にして処理の流れを描けたら、あとはAIにコード書いてもらったらよろし。
あと結論というか所感やけど、基本的にgemに頼ったほうがいいと思うわ。
deviseを使わない認証
認証機能を実装するんやったら、脳死でdeviseインストールしてんねやろ。
Rails 8やったらメールアドレスとパスワードの方式での認証機能は標準搭載してるで。
おれアプリはGoogleアカウントでの認証にしたから、これ使ってないけど。
将来的にはパスワードレスな認証方法も、標準搭載かgemになるかは分からんけど、提供してくれるかもやで。
DHHが「パスキー認証ええよな！ただ、まだ時期尚早やと思うねんな」的なこと言うてるわ。
パスワードレス認証がgemに切り分けられるんやったらgem追加せないかん問題は解決できんけど、公式的なgemになるんやったら継続的にメンテされる度が上がっていいやんね。
CarrierWaveとMiniMagickを使わない画像最適化＆アップロード
なんかアップロードするんやったら、とりまCarrierWave入れるやんな。
そんで用途は概ね画像のアップロードやろ。
動画とか音声やとファイルサイズでかくてそのまま扱うには処理速度的にもストレージのコスト的にもキツイし、最適化するにも処理に時間かかるしな。
そんでもってMiniMagickと併せて、画像のサイズとか形式を変えるやろ。
スマホで撮った画像とか、画像素材サイトの画像やと1MB超えることざらにあるしな。
画像をデカく使う必要ないんやったら、デカ画像まんまアップロードはストレージとか転送料の無駄が多くてイヤや。
これはRailsに標準で搭載されてるActive Storageで概ね解決できるでしらんけど。
なぜなら使ったことないんでね。
ただ、画像の最適化にはimage_processingっていうgem要りそうやわ。
image_processingのリポジトリ見るに、Railsの公式感は見受けられんね。
ただ、おれが参照した公式っぽいドキュメントで案内されてるgemやし、多少のgemの追加に目を瞑れるんやったら、Active Storage + image_processingでええんちゃう。
おれはgem追加に目瞑れんかったから、JavaScript使って画像の最適化とアップロード実装したわ。
JavaScriptを使った画像最適化アップロードの流れは以下や。
- 画像をアップロード
- Canvas APIで画像を最適化
- 2.の画像をbase64に変換
- 3.のbase64を
form.text_fieldのvalueに割り当て
以上や。
ブラウザ側で最適化するんで、でかい画像をPOSTせんで済むところが気に入っとる。
1MB超えの画像をPOSTしたユーザーの目線を想像すると、処理に時間かかってブラウザのタブのローダーが長々とグルグル回ってて「おせーわはよ終われ」ってなりそうやし、タイムアウトでエラーになる可能性ある。
前述の画像最適化アップロードの挙動を収めた以下のgif見てや。
伝わるか分からんけど画像をアップロードしたら待ち時間が無しに、最適化された画像がすぐに表示されんねん。
このgifでアップロードしてる画像は元が1920×1280の1.5MBのjpgで、アップロード後に表示された画像は720×480の49.2KBのjpgや。
高速でむっちゃ軽なったで。
ちなみにブラウザがSafari以外やったらwebpに変換できるんで、さらに軽なるで。
ただ、前述の通りActive Storageとimage_processingでアップロードも最適化もできるんに、わざわざ別の言語のJavaScriptを書いてんのは個人的にモヤるところや。
とはいえ、そんな思いを汲んでサーバーは「JS書くのだるいんやんな。ほなアップロードど最適化に掛かるコストはチャラにしたるし、優先的に処理して高速化したるわ」とは言ってくれんし、ユーザーからしたらRubyとかJavaScriptとか知ったことやない。
Ransackを使わない検索
おれアプリでは検索機能を付けんかったけど、検索機能を実装するってなったらRansackがよう使われてる気するわ。
ただ、キーワードでの検索やったらwhereでできるで。
あとどうせチェックボックスとかセレクトボックスとかで選択した値を、検索する際の条件として利用したいんやろ。
したら、その辺の条件をクエリパラメーターに追加したらええねん。
ほんでコントローラーでクエリパラメーターから各条件を取得して、クエリにくっつけたら条件付き検索できるやろしらんけど。
Kaminariを使わないページネーション
ページネーションのgemと言えば、Kaminariやな。
これに関してもおれアプリでページネーションを付けてないんやけど、limitとoffset使えば実装できるやろしらんけど。
ほんでページの総数は、要素の総数 / 1ページあたりに表示する要素数で計算して、余り出たら+1でOKやんしらんけど。
Gretelを使わないパンくずリスト
以下の記事の通りで問題なくパンくずリストを実装できるで。
MetaTagsを使わないメタタグ
content_for :head doで余裕で実装できるな。
「指定が無い場合はデフォルト値を割り当てたい」とか「ルートページ以外は現在のページ名 | アプリ名みたいなタイトルにしたい」とかは、ヘルパーつくってapplication.html.erbでつこたらええ。
MiniMagickを使わない動的OGP
これはVanilla Rubyでやるんは実質無理やな。
やからCloudinary使お。
Zennがまさにつこてんな。
でもサードパーティーサービス使うんやったら、MiniMagick使ってもええと思うわ。
動的OGPをサードパーティー無しに実装するんは、わしら凡人には無理ゲーやんな。
基本的にgemを導入した方がええと思う
なぜなら、考慮されてる事項が多そうやからや。
例えばおれアプリで実装したブラウザ側での画像の最適化アップローダーやけども、1.5MBのjpgと1.5MBのpngでの挙動でしかテストしてない。
gifとかwebpとかavifとかアップロードされたらどうなるんか把握してない。
アップロードしたデバイスのスペックが低い場合、かつ5MBとか1GBとかのデカファイルをアップロードされたら、処理が止まるかもしれん。
画像ファイル以外をアップロードされた場合にどうなるかは、予想できるけど断言できん。
こんな感じで、おれがテストしたり上記の想定した範囲は、巷の永く広く使われてるgemと比べてむっちゃ狭いと思う。
かたや永く広く使われてるgemは、おれより遥かにつえー人が開発して、たくさんの人がコントリビュートしてるやろ。
永く広く使われてるgemは、おれらいち開発者が想定しきれん使い方を考慮して実装されてんねんしらんけど。
とはいえ、使ってたgemがメンテ終了なった経験ある人は結構おると思う。
記憶に新し目のヤツやとSorceryかね。
メンテ終了ってわけやないけど、当記事で言及したRansackは2024年夏からアップデート無いしPRのマージもされてないしで、諸々と止まってんちゃうかな。
gemやないけど、いわばReactの公式的なライブラリやったのにアーカイブされた、Recoilっていう例もあるで。
やから"基本的に"やな。
「少しでもメンテ終了リスクを下げるためにgem使わずに実装するんや」って言うんやったら、同機能を提供するgemの実装を見て、最低でもそのgemが考慮してる実装なりエラーハンドリングはせなあかん、っていう気持ち持っとこな。
こと仕事においては。
ただ、gem追加禁止縛りプレイによって、アルゴリズム考えたりgemの実装を参考にしたりする機会が生まれて学び多いんで、全人類定期的やるのええと思うわ。
gem追加禁止縛り掲示板WebアプリデプロイRTAおもろそうやん。
Railsはサードパーティへの依存を減らしてってるし、Rails使いにはちょうどええ機運や。
Discussion