このテーマ。僕はずっとずっと悩んで来た問題です。railsdm周りで話題になってたっぽい。
ベストプラクティスというものはまだ見えない。
でも、いろいろな実績が出て来たし、自分でもいろいろやって見たのでまとめて行きたいと思います。
1. sprokets + turbolinks + webpacker + stimulus
basecamp wayですね。
それぞれハマりどころが多くrailsに精通していないと使いにくいと思います。
DHH信者にオススメの設定です。
Rails Way は良きものだけど Basecamp Way はガン無視しますね
— たにみち (@ttanimichi) 2018年3月28日
気持ちはわかるけど、染まって見るのもなしではないかな。
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をコントロールするのに融通が効かないのは嫌だという場合にオススメな構成。
#railsdm webpacker 存在がdhhがwebpackオプションの解釈をミスって実装された本物のゴミなので webpack-minfest-plugin とそれを読む helper を自分で用意してください。あとハッシュダイジェストの厳密性そこまで今優先度高くない
— human eslint --fix (@mizchi) July 14, 2018
確かにハッシュダイジェストは捨ててもええっすね。
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が最も辛い。