Fluxを使ったScalaJSの二層式フロントエンド
自己紹介
- @kyo_ago
- ChatWorkの中の人です
- 仕事では主にフロントエンド向けScalaを書いています
Fluxを使ったScalaJSの二層式フロントエンド
もうちょっとわかりやすく
ScalaJSを本番投入しようとしてる話
なぜか
サーバサイドのコードと透過的に触れるようにしたい
設計を共有したい
「サーバサイドの実装が終わってもフロントエンドの実装待ちでリリースできない」自体を減らしたい
問題1
JS部分との連携が特殊になる
解決策
解決策
- DDDでドメイン領域とインフラストラクチャを分ける
- ドメイン領域、アプリケーション領域はほぼ普通のScalaで書ける
問題2
UI部分はゆるく書きたい
解決策
解決策
- フロントエンドを「Frontend-backend」と「Frontend-frontend」に分けてpostMessageで通信する
- Frontend-frontendはFluxを採用してFrontend-backendから送られてきたメッセージを流すだけにする
- Frontend-frontendで発生したイベントはpostMessageで投げてFrontend-backendで処理する
二槽式
二槽式
- Frontend-backendはそのままWorkerで動作するレベルの独立性にする
- 構成的にはほぼサーバサイドと変わらない構成でいける
- Frontendにマイクロサービスができるイメージ
- もちろんScalaJSでなくても使える(もともとはTypeScriptで実装する予定だった)
二槽式
- メッセージのやり取りが煩雑になるのは許容する
- メッセージのみでUIが構築できればデバッグは非常に楽になる
- 普通はリソース的にもあまりペイしないと思うのでおすすめはしない
- Chrome extensionのbackground pageでは使える構成
FAQ
FAQ
- Q 辛くない?
A ぶっちゃけScalaに慣れてればTypeScriptでES6 module構成取るより辛くない
- Q ScalaとScalaJSの差分は?
A enum周りは若干あるけど、それ以外はほぼ誤差。Scalaやってる人的にも「いけるのでは」
- Q コンパイル遅いんだよね?
A ScalaJSはそんなに遅くは感じない(Closure compilerにかけなければ)
- Q JS部分との相性は?
A その辺を無視したくて二層式にした(この構成なら気にならない)
FAQ
- Q FrontendとBackendのコード共有ってできるの?
A ぶっちゃけあまりできない。Scala側でJavaを触ってることが多い。設計とリソースの共有が主
- Q 周辺ツールは?
A IDEはIntelliJがある。sbtは辛いけど社内に職人いるので何とかなった
- Q デバッグは?
A Sourcemap対応してるのと、ES6出力すれば結構読める(最近Strong mode対応した)
FAQ
- Q Scalaの言語的リスクは
A 採用事例は多い。プロダクトの寿命より短いことはないと判断
- Q ScalaJSのリスクは
A 現時点ですでに機能的には十分(今はJavaのコードをScalaJS用にScala化してる)。最悪ここで進化がとまっても大丈夫と判断。ただ、Scala的にもScalaJSはかなり押しっぽい(JVM以外の足がかりがほしいっぽい)ので、今後非互換の機能が入る可能性は低いと思う(Scalaも次のバージョンで中間言語化されるし)
ご清聴ありがとうございました