(cache) isomorphic tokyo meetupの感想とメモ・資料 #isomorphic_meetup

<a href="http://nodejs.connpass.com/event/13363/">isomorphic tokyo meetup (2015/04/30 19:30〜)</a>nodejs.connpass.com

ニフティの場所難易度高い＆都庁前駅でGoogleマップ使ったら現在地が御徒町になるなどのトラブルがあり、最初の発表の半分くらいを聞き逃したorz

感想

真のIsomorphic（Truly Isomorphic）ってのがよくわかってなかったが、「IsomorphicってServer Side Renderingのことっしょ？」に対する「いやいや、Viewだけじゃなくて全部が両方で動くことやで」みたいな理解であっていますでしょうか？
- 「Server SideレンダリングできるとSEOにいい」とか個別の事象に対して注目してしまっているので、
- 新しい技術や流行りの技術が出てきたことによってArchitectureがどう変化したかや、
- それらが生まれる背景にある課題など、
- もっと俯瞰して見る必要があるなと感じた。
@koichikさんの歴史から辿っていく感じの発表が非常に面白くて、聞き逃したのが本当に悔やまれる
- Mojitoを結構触っていた時期があったので、Mojitoという言葉が出てきた時点でかなり高まった
- Rendrは結局触ってないなーと思ったけど、React、Fluxが出てきてもう今からは手を出さなくてもいいかなという気持ち
- Fluxibleは出た頃にちょっと触って「あーこれちょっとゴツイなー」と思って追っていなかったが、Fetchrはよさそうなので、他のFlux実装と組み合わせて使いたい
Scala.jsの話はピザ食いながらだったのでメモあまり取れなかった。
- Scala好きだったらすごく楽しい発表だったろうなー。
- 興味はあるので、取っ掛かりとしてScala.js使ってみようかな
- APIリクエストの型判定（で合ってるか？）の話とか、BinaryでSerializeして渡すやつの話はすごい面白かったー。
Service WorkerをタダのキャッシュとかProxyやろと思っていたところがあるが、mizchiさんやJxckさんみたいなFEとBEの中間のレイヤとして捉えて、FEのインターフェースを考えなおすみたいな発想（なんか既にうまく説明できてない）はしたことなかったし、あんまり重要と思っていなかったので、再考したい。

「あー早く帰ってコード書きたい＆読みたいー！」みたいな感じになる、すごくいい勉強会だった！！が、Isomorphicは結構追っていたのに理解力が追い付いていない部分が多々あり、危機感を感じたので、本日の資料を見ながらよく考えねばと思った。

以下、メモや資料

「Isomorphic Survival Guide」 by @koichik

（遅刻したため、途中からしか聞いてない。。）

先駆者

Flation（Nodejitsu）
- http://flatironjs.org/
- 生みの親
- 小さなIsomorphicライブラリの集まり
- 忘れられた存在
Mjito（Yahoo）
- Yahooほぼの規模がないとねー
Meteor
- Minimongo
- PhantomJSでサーバサイドレンダリング
  - Isomorphicと呼んでいいか微妙
- backendをclientとserverで使う
Truly Isomorphic
- だいぶ小さなライブラリになりそうな気がする

課題が重要

Isomorphicの先駆者がぱっとしてない
- Flatiron 課題が不明瞭
- Mojito 課題がニッチ
- Meteor 人類には早い

Rendr

Airbnb
Backboneベース、フロントエンドのIsomorphic
SPAの課題解決
- 初期表示が真っ白
- SEOが弱い
  - 注意）2012-2013年頃の話、クローラーの進化やHTTP/2で解決するかもしれない
BackboneのIsomorphic化
- 独自のRouter
  - Client:backbone router, Server:express router
- Controller
  - パラメタのModelに渡す層
- Modelのsync
  - Server sideではrequestを使う
- View
  - handlebarsを使う
  - dehydrate, haydrate
    - dehydrate ModelをシリアライズしてViewへ（JSON）
    - hydrate Client側でデシリアライズしてModelを復元
レンダー用のServer（JS）は何と呼べばいいのか？
- rendering server?
- 否。
  - BEサーバとproxyするmiddlewareが提供されていた
Backendがステートレスにできる
Orchestration
- Server(JS)とBEが1対多
- microservice
- http://microservices.io/patterns/apigateway.html
Rendrはなぜ流行らなかったか？
- Angularがめっちゃ流行ってた時期。

React

みんな、知ってるよね？
Flux オレオレ実装乱立
- flux comparison
Singleton free
- FacebookはStore, Dispatcherをシングルトン推奨
- サーバではリクエスト毎にデータを共有してしまうのでダメ
- Store, Dispatcherをシングルトンにしてない実装が多い
  - contextにまとめる
- Routing
  - React Router
  - Flatiron Director
- Fetching
  - superagent
  - isomorphic fetch
    - https://github.com/matthew-andrews/isomorphic-fetch
実装
- Flummox
  - 人気っぽい
  - simple
  - serialize, deserialize
  - IsormorphicなFetcher
    - そのまま使うとFEが直接BE叩くようになる
    - API Gatewayにするためには工夫が必要
- Fluxible
  - Yahoo
  - 重厚
  - Pluggable
    - Routr, Fetchr, Dispatchr
    - ↑はFluxibleには依存してないのでfluxible-*系を使う
    - 結構大きく変えている
  - Fetchrの旨味
    - Serviceというオブジェクトを直接呼び出す
    - NOT Isomorphic, Server side ONLY
    - Client sideの場合はAPI経由で呼び出す
      - fetchrが提供するexpress middleware

まとめ

FE/BEをC/S両方で動かしてブレークスルー
- 共通化

「Isomorphic Web development with Scala & Scala.js」 by @TanUkkii

Isomorphic web development with scala and scala.js from TanUkkii

www.slideshare.net

Web FE Engineer
C/S間で
- 開発環境の共有
Motivation
- spray使ってる
- Api Exproler作りたい
- scala.jsでIsomorphicやりたいでござる
開発環境の共有
- sbt Java/Scalaのビルドツール
- multi project build
addSbtPluginでscala-jsを

「実践isomorphic(+ Electron)」 by @mizchi

speakerdeck.com

@mizchi
isomorphicの目的(個人的な）
- どこでも動くものを提供したい
  - DOMから独立したWorker環境
  - ヘッドレステスト
- node.jsのエコシステム
  - ライブラリ提供時は常に意識する必要性
- MVC強制ギブス
  - MVCでいうViewが触りづらい
  - ドメイン層に注力
一昔前→JSとJQueryの区別がなかった時代
ex) marked
- node, browser, workerでも動く
PhantomJSへの敵意
- 不安定、重い
グローバル空間
- window, global, self
環境依存
- document, navigator, setImmediate などなど
- require
実際には
- node, browserのみ対応していれば
ネイティブモジュールは使えない
- どうしてもの場合は、emscripten
commonjs
- webpack browserify, require1k, duojs
- ASTを変換する
- require(変数)ができないとかある
lib以下にフラットなJSを吐く
- 単体でテストできるように
watchifyつかえ
- インクリメンタルビルド
ES6のimport/export
- babelはrequire
- TypeScriptはexport defaultは未対応
Electron
- windowとglobalが共存、トップレベルthisはwindow
Electronでのbrowserify
- node_modulesの中で必要な物だけ欲しい
- 250MB -> 2.2MB
- 一部browserify出来ないものは、global.require('app')する
  - bad knowhowやけどな
DOMとは
- GUI ツールキット
- EmbededなChromeを含むのでバイナリは大きい
Electronのいいところ
- 環境の固定
NetworkのIsomorphic
- Service worker内でExpress likeなrouter
- mizchi/sabizan

「Unified Interface on Isomorphic JavaScript」 by @axross_

Unified Interface on Isomorphic Javascript from Kohei Asai