Share
Embed
Slide 1
Slide 1 text
Layerd APIs
(LAPIs)
#tng30 2018/4/27 Jxck
Slide 2
Slide 2 text
Extensible Web
2
Slide 3
Slide 3 text
3
Slide 4
Slide 4 text
4
Low Level APIs
● Encoding
● URL
● Fetch
● Stream
● Custom Elem
● etc, etc, etc
Slide 5
Slide 5 text
5
High
Low
ExtensibleWeb
Scope
Out of Scope
Do It Yourself
Slide 6
Slide 6 text
Async Local Storage
6
Slide 7
Slide 7 text
Storage APIs
7
Window
● IndexedDB
● CacheStorage
● LocalStorage
ServiceWorker
● IndexedDB
● CacheStorage
Slide 8
Slide 8 text
Storage APIs
8
Window
● IndexedDB
● CacheStorage
● LocalStorage
ServiceWorker
● IndexedDB
● CacheStorage
Sync API not Allowed
async
async
sync
async
async
Slide 9
Slide 9 text
missing point
● version とか flag のような少量のデータもある
● それを保存するのにも IndexedDB 。。。
● window 側にも Async API は欲しいし
● 原因が Sync なら Async API の可能性があっても
良いのでは?
● それなら Cache API は AsyncLocalStorage の
特化 API と見ることができる。
● そもそも突然出てきた Cache API の特異さ
9
Slide 10
Slide 10 text
Propose Async Storage
10
提案、というか「考えてみてもいいの
ではないか？」という提案の手前の提
案を discorse に投げてみる。
https://discourse.wicg.io/t/asynclocalstorage/1554
Slide 11
Slide 11 text
Propose Async Storage
11
● それ localForage でできるよ
● それ lovefield でできるよ
● それ IndexedDB でできるよ
● それ etc, etc, etc
知ってた！！！
https://discourse.wicg.io/t/asynclocalstorage/1554
Slide 12
Slide 12 text
1 year later
12
Slide 13
Slide 13 text
13
!!?
Slide 14
Slide 14 text
14
Slide 15
Slide 15 text
15
Slide 16
Slide 16 text
https://docs.google.com/document/d/1VbU4z7xtU_kzuLAcj38KKL5qoOr2UYNUJW8vZB2AcWc/edit 16
Slide 17
Slide 17 text
17
https://docs.google.com/presentation/d/1_5EVAiuragdEqop8V9b1hJkOW38y4EsXYgNBKdpSHmA
Slide 18
Slide 18 text
18
Layered APIs
Slide 19
Slide 19 text
19
課題
● High Lvl API は Out of Scope だったが
○ 読み込むアセット(library) の量は増え続ける
○ High Lvl とはいえコモンケースはあるのでは？
○ 無視し続けて良いのか？
○ 「シンプルに保つ」vs「進化し続ける」
● Low Lvl API が軌道に乗った今
○ この基盤を安全に拡張し High Lvl API も考えたい
○ 策定コスト、安全性、互換性なども考慮したい
○ うまくいけばネイティブ実装していけるのでは
Slide 20
Slide 20 text
Layered APIs (LAPIs)
● Low Lvl API をベースに High Lvl API を実装
○ とはいえ FW ほど高くはない
○ 多くのユースケースで共通して使われてるもの
○ ネットワークコスト/パフォーマンス向上
● 標準化プロセスは他の API と基本同じ
○ 特別扱いはしない
● Polyfill をうまく使い漸進的に進める
○ フォールバックのために import を拡張
○ Ship されたら polyfill を fetch しないで済む
20
Slide 21
Slide 21 text
21
High
Low
Extensible
Scope
LAPIs
Scope
Slide 22
Slide 22 text
22
Layered APIs Proto-spec
import { storage } from
"std:async-local-storage|https://cdn.example.com/async-local-storage.js";
await storage.get("key")
...
Slide 23
Slide 23 text
23
Layered APIs Proto-spec
...
import { storage } from
"std:async-local-storage|https://cdn.example.com/async-local-storage.js";
await storage.get("key")
std: に実装されると Polyfill は fetch する必要すらなくなる。
Slide 24
Slide 24 text
LAPIs Infrastracture
● global を汚さないように import で opt-in
● polyfill へのフォールバックを前提
● 漸進的に解決する大枠
● このインフラの上に実際の API を構築してく
● 今日 Chrome の Intents が出た(16h 前)
○ Intent to implement: Layered API infrastructure
○ https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev
/MFbJuzA5tH4/t6Q-LZHpAgAJ
24
Slide 25
Slide 25 text
基本方針
● ブラウザが外に出してない機能は使わない
○ Polyfill できないもの(== magic)はだめ
○ 不足する Low Lvl API があるならそれを先に標準化
● 影響は閉じるように進める
○ モジュールに閉じ、グローバルを汚染しない
○ Array.prototype への追加などは影響が多いので難しい
25
Slide 26
Slide 26 text
Starting Point
● async-local-storage
○ https://github.com/domenic/async-local-storage
○ IndexedDB だけで実現できる
● infinite-list
○ https://github.com/domenic/infinite-list-study-group
○ デフォルトスタイルについて要件がキツくない用途
● tasklets
○ https://github.com/GoogleChromeLabs/tasklets
○ promise base api を worker でやって返す API
26
Slide 27
Slide 27 text
In Node.js
27
Slide 28
Slide 28 text
Adding Websocket support to core #19308
● tl;dr;
● こういうことは今後起こり続ける
● 「シンプルに保つ」vs「進化し続ける」
● 考え方は同じなのでは？
28
Slide 29
Slide 29 text
kmiller68/module-fallback-imports
import "std:Array.prototype.flatten"
else "url-to-fallback";
import ["std:Array.prototype.flatten",
"url-to-fallback1",
"url-to-fallback2"]
29
duplication effort !?
Slide 30
Slide 30 text
30
Slide 31
Slide 31 text
懸念
31
Slide 32
Slide 32 text
premature-polyfill ?
import { storage } from
"std:async-local-storage|https://cdn.example.com/async-local-storage.js";
● std: がブラウザに ship され、polyfill と API が違ったら?
● premature-polyfill 問題
○ polyfill に引っ張られて API が更新できない問題
○ Polyfill のあり方と Web の進化と協調するためのガイドライン
● これが解決しないと歴史を繰り返すのでは?
○ https://github.com/drufball/layered-apis/issues/12
32
Slide 33
Slide 33 text
まとめ
● LAPIs
○ まだ始まったばかりの提案
○ Low Level API が一定の成果を出したからこそ
○ High Level API にも目を向けるには良い時期かも
● 方針
○ opt-in で global を汚さない
○ pollyfill への fallback
○ magic は使わない
○ 漸進的な解決策
● 課題
○ premature-polyfill はどうするのか？
○ Node でも上手くいかないか？
● いろんな意味で今後に期待
33
Slide 34
Slide 34 text
Jack
thanks
Slide 35
Slide 35 text
Feature detection LAPIs itself
(async () => {
let layeredAPIsSupported = false;
try {
await import("std:blank");
layeredAPIsSupported = true;
} catch {}
if (!layeredAPIsSupported) {
// Load polyfills the old-fashioned way.
}
})();
35