Isomorphic Architecture & Interface

Isomorphic
Architecture
&
Interface
2015/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 的な
C
V M
C
V M
C
V M
C
V M
FrontEnd BackEnd
Nginxluamodule

2014末
V-DOM により
Rendering が View から切り離された。
だいたいの話ですって
Rendering 本当の対象外
C
V M
C
V M
C
V M
C
V M
FrontEnd BackEnd
Nginxluamodule

2015
SW によりフロントにも Proxy Layer が入った。
まあ、考え方の一つとして
C
V M
FrontEnd BackEnd
C
V M
Nginxluamodule
ServiceWorker
Rendering

2016
Nginx に JS モジュールが入る？
http://nginx.com/blog/nginx-open-source-reflecting-back-and-looking-ahead/
予定です
C
V M
C
V M
C
V M
C
V M
FrontEnd BackEnd
ServiceWorker
NginxJSmoduleRendering

i8c
Proxy のレイヤは何をするか
C
V M
C
V M
C
V 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
アプリから見える世界を奇麗にするために
汚れ仕事を受け入れるレイヤ
C
V M
C
V M
C
V M
C
V M
Nginx+JS
SW
Protocol JS
Rendering
JS
3 つ目のレイヤとつなぎ

i8c
ここを繋ぐ決まりが無い
C
V M
C
V M
C
V M
C
V M
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) {
};
本当に欲しいインタフェース

結果
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

Isomorphic Architecture & Interface

More Related Content

What's hot

Similar to Isomorphic Architecture & Interface

More from Jxck Jxck

Isomorphic Architecture & Interface