isomorphic architecture & interface

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