読者です 読者をやめる 読者になる 読者になる

pirosikick's diary

君のハートにunshift

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

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

speakerdeck.com

(遅刻したため、途中からしか聞いてない。。)

先駆者

  • Flation(Nodejitsu)
  • 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
  • レンダー用のServer(JS)は何と呼べばいいのか?
    • rendering server?
    • 否。
      • BEサーバとproxyするmiddlewareが提供されていた
  • Backendがステートレスにできる
  • Orchestration
  • Rendrはなぜ流行らなかったか?
    • Angularがめっちゃ流行ってた時期。

React

  • みんな、知ってるよね?
  • Flux オレオレ実装乱立
    • flux comparison
  • Singleton free
    • FacebookはStore, Dispatcherをシングルトン推奨
    • サーバではリクエスト毎にデータを共有してしまうのでダメ
    • Store, Dispatcherをシングルトンにしてない実装が多い
      • contextにまとめる
    • Routing
      • React Router
      • Flatiron Director
    • Fetching
  • 実装
    • 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

www.slideshare.net

  • Web FE Engineer
  • C/S間で
    • 開発環境の共有
  • Motivation
    • spray使ってる
    • Api Exproler作りたい
    • scala.jsでIsomorphicやりたいでござる
  • 開発環境の共有
  • addSbtPluginでscala-jsを

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

speakerdeck.com

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

「Unified Interface on Isomorphic JavaScript」 by @axross_

www.slideshare.net

  • @axross_
    • Asaiさん
  • 社内ツールでIsomorphicした話
  • Try
    • IF統一、Validator統一
  • Interface統一
    • SPAだとクラス欲しい
    • コミュニケーションコスト
  • Validation統一
    • 分かれてるとリスキー
    • toJSON, fromJSONでValidate
  • Server Side Rendering
    • あんまやってない
  • まとめ
    • Client Sideはすごく書きやすい
    • Serverはそんなに。。
    • 区切りを薄くするといいで。

「Isomorphic Architecture & Interface」 by @jxck

  • @jxck
    • 今日定時ダッシュして書いた。
  • やみくもにisomorphic isomorphic言ってねえか?
  • よく言われる
    • ロジック共通化、ブラウザ無しでテスト。。。
    • 現実
      • validationくらいしか
      • 結局ブラウザテストいる
  • 何があり、何がないか
    • 部品はある、V-DOM、browserify、moduleなどなど
    • Architectureがないのでは
    • Interfaceがないのでは
  • Architecture
    • DOMに依存しないという話だったが、V-DOM出てきたし、SW出てきたし、NginxでJS書けるようになるしー
  • Proxyの役目
    • Nginxは何をしていたか
      • SSL, IPフィルタ、ルーティングなど
      • zip圧縮、ヘッダ追加、コネクション保持など
      • プロトコルをオブジェクトに、共通処理
    • SWで何ができるか
      • fetch/onfetch, websocket, onpush
      • WSかXHRかの九州
      • IndexedDBかLocalStorageの九州
      • Nginxと同じじゃね?
    • アプリのめんどいとこをがっつりと減らすレイヤー
  • インターフェース
    • JSとProxy間のインて~フェースがない
    • Req, Resを渡す層がない
      • connectは枯れてるけどNode前提
  • Streamに抽象化しよう
  • エコシステム
    • middleware
    • container
      • FWから無駄を排除
    • mindset
      • どっちで動くかからの脱却
      • このインターフェースに依存する
  • i8cを加速する
    • 枠組みを整えよう
    • 車輪に載ってFWが作れる
  • やみくもやめよう
    • 消耗しすぎ、効率よく
    • 最大の敵
      • Node/IO.js core team
      • i8cに興味ない
      • Streamの共通化やってほしい
    • URLのパースができはじめた
      • Jxck/URL