dreamin' blog

このテーマ。僕はずっとずっと悩んで来た問題です。railsdm周りで話題になってたっぽい。

ベストプラクティスというものはまだ見えない。 でも、いろいろな実績が出て来たし、自分でもいろいろやって見たのでまとめて行きたいと思います。

1. sprokets + turbolinks + webpacker + stimulus

basecamp wayですね。 それぞれハマりどころが多くrailsに精通していないと使いにくいと思います。 DHH信者にオススメの設定です。

気持ちはわかるけど、染まって見るのもなしではないかな。

2. webpacker + react(or other javascript view library) (+ some cssloader || sprokets)

部分的にreactなどのviewを使う設定。場合によってはcssもstylesheet_pack_tagを使うパターン。 個人的にはこのパターンってreact使う必要ある?という気もします。 が、例えばKPIに直結する非常に重要な機能だけをSPAにして、 UXを最大化するのに使える構成ではあると思います。

この場合はsproketsを捨てない方が無難な気もしますが、 reactの中でcssを使いたい場合や、依存ライブラリをいい感じにシュッとしたい場合はwebpackerに頼ってしまうのもいいでしょう。

3. webpack + rails(without sprokets and webpacker)

例えばsproketsを捨てるのようなやつ。 railsでレンダリングするのは完全に捨てないまでも、 webpackerを通じてwebpackをコントロールするのに融通が効かないのは嫌だという場合にオススメな構成。

確かにハッシュダイジェストは捨ててもええっすね。

4. webpack + rails api

railsは完全にapiに成り下がるパターン。 フロントエンドは完全にjavascript wayに集中できる。 しかしながらSPAで全部作るのは大規模案件には骨が折れる作業にはなりそう。 特に管理画面系なんかはまだrailsに一日の長がある印象。

管理画面は別でrailsでサクッとmicroserviceで作ったりrails engineを採用したり工夫すると工数の削減も進むかも。 BFFとしてのrails apiといったところ。

ただ、そもそもBFFをrailsがある必要がどこにあるだろう。 他の言語でもswaggerやgraphqlを利用すればrails並みに工数を削減することもできるだろうしね。

けど、それでもrailsがいいって時はこれが無難ですよね。

まとめ

個人的にはオススメは4。逆に1という手もある。 一般的には2,3が多いけど、2,3が最も辛い。