Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
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: htt...
最近ぼんやり思ってるけど
固まりきってない話です
やみくもに
isomorphic isomorphic
 言ってませんか?
● ロジックの共有
● ブラウザ無しでテスト(大事)
● npm でモジュール管理
● アプリが両方で動く
よく言われる isomorphic
● logic の共有
○ あれ? validation しか共有できない。。
● browser 無しでテスト
○ でも結局ブラウザでしか動かさない。。
● npm でモジュール管理
○ それ babelify しただけちゃうん?
● アプリ...
何があり
何が無いか
● 部品
○ 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
Nginxluamo...
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 ...
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 を吸収
○ イベントに変えてしまう
● イベントでの抽象...
● プロトコルをオブジェクトに
● 変なのをフィルタリング
● 共通処理の代替
アプリが見える世界を奇麗にし、考えること
を減らす。
Nginx と同じ事ができるのでは?
i8c
アプリから見える世界を奇麗にするために
汚れ仕事を受け入れるレイヤ
C
V M
C
V M
C
V M
C
V M
FrontEnd BackEndMiddle Proxy
Nginx+JS
SW
Protocol JS
Renderi...
インタフェース
i8c
ここを繋ぐ決まりが無い
C
V M
C
V M
C
V 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/Respo...
● 繋ぎっぱなし/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 ReadableSt...
結果
FrontEnd BackEndMiddle Proxy
ProtocolJS JS
Req / Res
Readable /
Writetable
Req / Res
Readable /
Writetable
● middleware
○ connect middle の発展系
○ whatwg transform stream で流れを変える
● container
○ FW から面倒/共通な部分を引きはがす
○ MV* はお前が思う最強のでやれば...
● 今
○ 部品は揃った
○ 各々がやみくもに進んでる
● 提案
○ 枠組みを整えよう
○ 再利用/共有可能なモジュールを作ろう
● 理想
○ 車輪に載って FW が作れる
○ エコシステムの加速
i8c を加速する
● 効率よく
○ Web アプリはエコシステムで作るもの
○ 一人で全部を作る必要は無い
○ みんなで同じものを作る必要は無い
○ 本当に大事なアイデアに注力したい
● コアは?
○ Node/IO.js のコアも歩み寄って欲しい
○ modu...
thanks :)
Extend the Web Forward
Jack
Upcoming SlideShare
Loading in …5
×

Isomorphic Architecture & Interface

4,468 views

Published on

isomorphic interface for front + proxy + back layer.
at #isomorphic_meetup

Published in: Technology
  • Be the first to comment

Isomorphic Architecture & Interface

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

×