たけてぃーの開発ブログ

エンジニア視点からWebサービスについて考える

フロントエンドの技術選定をした時に行ったこと(まだ検討中)

暑い暑いとても暑いです。

現在お仕事いただいてる現場でこんな話になりました。

僕「そういえばこのサービスではフロントエンドとバックエンドわけないんですか?」

先輩「今はPure Railsだけどそろそろわけないと限界かなぁ・・・じゃあフロントエンドと分けるためにはどうすればいい?何を使えばいい?」

僕「うーん・・・わからない」

先輩「じゃあ調べてきて」

というわけで、フロントエンドの技術選定を任されました。

やはり現代のサービス開発においてはWebAPIとフロントエンドを切り分けるのは当然の発想です。

qiitaに前に書いたので暇だったらどうぞ→エンジニア視点から見るWebサービスの全体像(qiita)

理想像

WebAPIとフロントエンドをきっちりわけて、フロントエンドをSPAに、WebAPIrailsからより高速な物に差し替える。

ついでにモバイルネイティブアプリも作れたならなぁ

満たすべき条件

こんな条件が挙げられました

  1. JS/CSS/HTMLまわりを一手に担ってくれること(フロントエンドフレームワークの必須要件?)

  2. ES6からトランスパイル、SCSSからCSSへのプリコンパイルが出来る。 できたらslimやjadeっぽい記法でHTMLが書けたら嬉しいけど必須ではない。

  3. 今後の時代の変化についていきやすいこと(エコシステムの存在・デファクトスタンダードになっていること、など)

  4. 何らかのユニットテスト機構が標準で入っているか、簡単に実行出来るようになっていること

デファクトスタンダードとは「事実上の標準」という意味です。

そもそもViewをレンダリングする方法について

主に3種類あるのではないだろうか

1.サーバーサイドのテンプレートエンジン

2.半々のもの(gemjavascript libraryを管理したり、埋め込み型)

3.完全に独立したhtml,css,javascript

将来的には3を目指したいが、2→3と開発を進めていくのが妥当かなぁと

そもそもフロントエンドにおけるフレームワークってなんなの?

僕「実はこの前Riot.js+Fluxフレームワーク(GitHub)みたいなの作ったんで使いませんか?gulpガッツリ書いて超効率よくかけるようにしましたよ!」

先輩「確かにそれはいいんだけど、主流に乗りたいし、それ誰が管理できるの?フレームワークとかないの?」

僕「そういえばフロントエンドのフレームワークってなんだ?」

調べてみたらフロントエンドにおける「フレームワーク」はテストツール、DOM操作、Ajax関係、mockなどなど多くの拡張ライブラリを備えたライブラリのことみたいですね(要検証)

RailsLaravelとか僕が思い浮かべてたフレームワークと呼ばれる物はYeomanなどのコードジェネレーターを使わなくちゃできないみたいです。

じゃあjavascriptのライブラリどうする?

結論から言うとReact.jsになりそうです。(僕はRiot.jsがすごい気に入ったんですがやっぱりあれば色々足りない・・・・)

理由: - Fluxがとても良く、それを良く実装できるから - コミュニティが大きい - 参考記事が多い - テストツールもある - ソースコードも綺麗にかける

まぁただ一つ嫌な点はjavascript中にhtmlを書くのが個人的には気に入らない・・・・

参考にした記事

Wantedlyの記事

React + Reduxを使ったWebアプリケーション開発速習会@Wantedly(qiita)

Railsで構築しているWebサービスをjQueryベースからReactに移行する時の知見

境遇が似てたWantedly様に圧倒的感謝!!!(いい記事ありがとうございますっ!)

最後に

まだ決まってるわけではないのですが、多分この方針でいくと思う。