Isomorphic Architecture & Interface

Transcript

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