isomorphic architecture & interface
TRANSCRIPT
IsomorphicArchitecture
&Interface2015/4/30 #isomorphic_meetup
Jack
● id: Jxck● github: Jxck● twitter: @jxck_● about: http://jxck.io● blog: http://jxck.hatenablog.com● podcast: http://mozaic.fm● Love: music
最近ぼんやり思ってるけど
固まりきってない話です
やみくもに
isomorphic isomorphic
言ってませんか？
● ロジックの共有
● ブラウザ無しでテスト(大事)
● npm でモジュール管理
● アプリが両方で動く
よく言われる isomorphic
● logic の共有
○ あれ? validation しか共有できない。。
● browser 無しでテスト
○ でも結局ブラウザでしか動かさない。。
● npm でモジュール管理
○ それ babelify しただけちゃうん？
● アプリが両方で動く
○ いや、やりたいこと違うんだけど。。
やみくも isomorphic
何があり
何が無いか
● 部品
○ V-DOM○ browserify
● module○ ES6○ npm
● WHATWG APIs○ fetch○ URL○ Promise○ Stream○ etc
あるもの
● i8c なコードを生かすアーキテクチャ
● それを支える共通インタフェース
無いもの
アーキテクチャ
~2013
i8c とは View(DOM) に依存しないことだった
だいたいの話
C
V M
FrontEnd BackEnd
C
V M
対象外？
2014
Nginx で終端+lua で色々いじり放題
micro services 的な
CV M
CV M
CV M
C
V M
FrontEnd BackEnd
Nginx lua m
odule
2014末
V-DOM により Rendering が View から切り離された。
だいたいの話ですって
Rendering 本当の対象外
CV M
CV M
CV M
C
V M
FrontEnd BackEnd
Nginx lua m
odule
2015
SW によりフロントにも Proxy Layer が入った。
まあ、考え方の一つとして
C
V M
FrontEnd BackEnd
C
V MN
ginx lua module
Service W
orkerRendering
2016
Nginx に JS モジュールが入る？http://nginx.com/blog/nginx-open-source-reflecting-back-and-looking-ahead/
予定です
CV M
CV M
CV M
C
V M
FrontEnd BackEnd
Service W
orker
Nginx JS
module
Rendering
i8c
Proxy のレイヤは何をするか
CV M
CV M
CV M
C
V M
FrontEnd BackEndMiddle Proxy
Nginx + JS
SW
この三つのレイヤが全て JS
Rendering
● Nginx は何をしていただろうか？
● SW は何ができるだろうか？
Proxy の役目
● Reverse○ SSL 終端
○ IP フィルタ
○ ルーティング
● Forward○ 圧縮
○ ヘッダ追加
○ コネクション保持
Nginx ができること
● プロトコルをオブジェクトに
● 変なのをフィルタリング
● 共通処理の代替
アプリが見える世界を奇麗にし、考えること
を減らす。
Nginx がしてきたこと
● 外界との中継
○ fetch/onfetch○ websocket○ onpush
● DOM 以外へのアクセス
○ storage○ cache○ UI との messaging
ServiceWorker ができること
● ネットワークアクセス
○ WebScoket か XHR か Push を吸収
○ イベントに変えてしまう
● ストレージアクセス
○ localStorage, IndexedDB を吸収
○ イベントに変えてしまう
● イベントでの抽象化
○ 余計な責務を UI 層から減らす
○ API が変わっても影響が閉じる
ServiceWorker が引き受けるもの
● プロトコルをオブジェクトに
● 変なのをフィルタリング
● 共通処理の代替
アプリが見える世界を奇麗にし、考えること
を減らす。
Nginx と同じ事ができるのでは？
i8c
アプリから見える世界を奇麗にするために汚れ仕事を受け入れるレイヤ
CV M
CV M
CV M
C
V M
FrontEnd BackEndMiddle Proxy
Nginx + JS
SW
Protocol JS
Rendering
JS
3 つ目のレイヤとつなぎ
インタフェース
i8c
ここを繋ぐ決まりが無い
CV M
CV M
CV M
C
V M
FrontEnd BackEndMiddle Proxy
Nginx + JS
SW
Protocol JS
Rendering
JS
3 つ目のレイヤとつなぎ
● 歴史的には
○ Request と Response を渡す
● 例
○ CGI○ Servlet○ Rack○ PSGI○ WSGI○ Connect?○ etc
ここのインタフェースこの部分の総称ってある？
● Connect○ ミドルウェアが多い、枯れてる。
● でも Node 前提
○ 手前に Nginx 立てないの？
○ http module 依存
● WhatWG が定義した
○ fetch の仕様の一部
○ Request/Response class● じゃあこれを返せばいいじゃん
○ 同期ではね
同期の場合
● 繋ぎっぱなし/Push○ WebSocket○ HTTP2○ SSE○ Coment
● その上のプロトコル○ MQTT○ JSON-LD○ msgpk-rpc○ grpc
● どうするか
非同期の場合
● Stream○ Node ではおなじみ
○ WHATWG Streams 定義中
● 全て Stream に抽象化しよう
○ 非同期に最適
○ その上に色々すればいい
全てのものは Stream だ
Stream
// 同期の場合
// WHATWG Request class
// WHATWG Response class
function (request, response) {
};
// 非同期の場合
// WHATWG ReadableStream class
// WHATWG WritableStream class
function (readable, writable) {
};
本当に欲しいインタフェース
結果
FrontEnd BackEndMiddle Proxy
ProtocolJS JS
Req / Res
Readable / Writetable
Req / Res
Readable / Writetable
● middleware○ connect middle の発展系
○ whatwg transform stream で流れを変える
● container○ FW から面倒/共通な部分を引きはがす
○ MV* はお前が思う最強のでやればいい
● mindset○ どっちで動くか？という考えからの脱却
○ インタフェースに依存する
○ やみくもにリソースを消費しない
エコシステム
● 今○ 部品は揃った
○ 各々がやみくもに進んでる
● 提案○ 枠組みを整えよう
○ 再利用/共有可能なモジュールを作ろう
● 理想○ 車輪に載って FW が作れる
○ エコシステムの加速
i8c を加速する
● 効率よく○ Web アプリはエコシステムで作るもの
○ 一人で全部を作る必要は無い
○ みんなで同じものを作る必要は無い
○ 本当に大事なアイデアに注力したい
● コアは？○ Node/IO.js のコアも歩み寄って欲しい
○ module さえあれば i8c で no-browserify
● 進捗○ やっと URL がパースできはじめた。。
○ https://github.com/Jxck/URL
やみくもな i8c から脱却しよう
thanks :)Extend the Web Forward
Jack