最近色々気づきがあったので memo
書いている人の前提
- Ruby on Rails エンジニア (webpacker 利用経験あり)
- webpack もわかる
- react, Angular, Vue.js 触ったことある
- css 周り(scss がメイン)
思ったこと
すげぇ今更だけど、しっくりきたので。
— こやつ(koyatsu) (@kaishuu0123) 2019年3月5日
Angular で MPA (Multiple Page Application) するのってちと面倒なんだ
な。Angular で MPA できれば概念的には一番いいんだけど。
React, Vue.js はその点部分的に導入するというのも可能で手軽だわね。(jQuery とかと似たような感じで使えるし)
上記の通りなんだけど、結論から書くと「新規で作るプロジェクトを無理して SPA にしなくてもいいんじゃないか。」という意見。
HTML への binding をしやすいという意味で jQuery は流行ったわけだし、react, Vue.js は jQuery の次のステップという意味でわかりやすい
Angular は SPA に特化しているイメージがあって、DI、Service 層など独自の概念が構築されていて、初期学習コストは高いかもしれないけど、恐らく SPA でエイヤと作るにはとても作りやすい (react とかで API 叩く層を作るとなると、redux-saga とかライブラリ選定から始まってしまう)
と考えると、採用技術は用途によって異なるわけだけど、恐らくまだまだ MPA(Multi Page Application: SPA の逆で従来の MVC フレームワーク(Rails とか)で実現している)が活躍しそうだと思っている。
せっかく Model を定義して、テンプレートエンジンに食わせて、 HTML を吐き出せるようにしているのに、わざわざ API を生やして、フロントエンド用にまたモデルを定義する意義、というのは有ることは理解できる、が、恐らく小さく始めるプロジェクトだと仰々しすぎる節がある。
じゃぁ、フロントエンド、バックエンドを分けるメリットを考えてみると、圧倒的にスケーラビリティという点で軍配が上がるし、責任分界点という意味でもチーム開発しやすい、という点もある。
逆にフロントエンドを SPA にするデメリットもあると思っていて、SSR 対応するときにめっちゃ辛い。Google さんから正しくレンダリングしてもらうためには、結局地道にページビューを確認していく作業が漏れなくついてくる(SSR 対応やった身からすると)
逆にフロント/バックエンドを分けないメリットを言えば、手元に一つの環境(MVC フレームワークが動作する環境)があれば、手軽に試すことができるという点。SSR を考えなくてもいい(かもしれない)という点。
分けないデメリットは、JS コードがスパゲッティになりがちになる。従来の jQuery を使った方法を取ると、あっという間に「どの JS がどの DOM をいじっているかわからん(´・ω・`)」となり得る。
けど、そういう場合って SPA でも同様のことが起きる可能性があると思っていて、結局は SPA/MPA での土俵で語ることではないと考えている
個人的にはプロジェクトは軽いところから、段々とスケールさせる方向に持っていく方が好みなんだけど、「最初からフロント、バックエンドが分離されていてよかったー!」という成功例も見てみたい。