2018年夏フロントエンド×Railsの事情

このテーマ。僕はずっとずっと悩んで来た問題です。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が最も辛い。