Upgrade to Pro — share decks privately, control downloads, hide ads and more …

web over layered apis

Jxck
April 27, 2018

web over layered apis

web over layered apis (LAPIs) at #tng30

Jxck

April 27, 2018
Tweet

More Decks by Jxck

Other Decks in Technology

Transcript

  1. 3

  2. 4 Low Level APIs • Encoding • URL • Fetch

    • Stream • Custom Elem • etc, etc, etc
  3. Storage APIs 7 Window • IndexedDB • CacheStorage • LocalStorage

    ServiceWorker • IndexedDB • CacheStorage
  4. Storage APIs 8 Window • IndexedDB • CacheStorage • LocalStorage

    ServiceWorker • IndexedDB • CacheStorage Sync API not Allowed async async sync async async
  5. missing point • version とか flag のような少量のデータもある • それを保存するのにも IndexedDB

    。。。 • window 側にも Async API は欲しいし • 原因が Sync なら Async API の可能性があっても 良いのでは? • それなら Cache API は AsyncLocalStorage の 特化 API と見ることができる。 • そもそも突然出てきた Cache API の特異さ 9
  6. Propose Async Storage 11 • それ localForage でできるよ • それ

    lovefield でできるよ • それ IndexedDB でできるよ • それ etc, etc, etc 知ってた!!! https://discourse.wicg.io/t/asynclocalstorage/1554
  7. 14

  8. 15

  9. 19 課題 • High Lvl API は Out of Scope

    だったが ◦ 読み込むアセット(library) の量は増え続ける ◦ High Lvl とはいえコモンケースはあるのでは? ◦ 無視し続けて良いのか? ◦ 「シンプルに保つ」vs「進化し続ける」 • Low Lvl API が軌道に乗った今 ◦ この基盤を安全に拡張し High Lvl API も考えたい ◦ 策定コスト、安全性、互換性なども考慮したい ◦ うまくいけばネイティブ実装していけるのでは
  10. Layered APIs (LAPIs) • Low Lvl API をベースに High Lvl

    API を実装 ◦ とはいえ FW ほど高くはない ◦ 多くのユースケースで共通して使われてるもの ◦ ネットワークコスト/パフォーマンス向上 • 標準化プロセスは他の API と基本同じ ◦ 特別扱いはしない • Polyfill をうまく使い漸進的に進める ◦ フォールバックのために import を拡張 ◦ Ship されたら polyfill を fetch しないで済む 20
  11. 22 Layered APIs Proto-spec <script type="module"> import { storage }

    from "std:async-local-storage|https://cdn.example.com/async-local-storage.js"; await storage.get("key") </script> <script type="module" src="std:virtual-list|https://cdn.example.com/virtual-list.js"> </script> <virtual-list>...</virtual-list>
  12. 23 Layered APIs Proto-spec <script type="module" src="std:virtual-list|https://cdn.example.com/virtual-list.js"> </script> <virtual-list>...</virtual-list> <script

    type="module"> import { storage } from "std:async-local-storage|https://cdn.example.com/async-local-storage.js"; await storage.get("key") </script> std: に実装されると Polyfill は fetch する必要すらなくなる。
  13. 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
  14. 基本方針 • ブラウザが外に出してない機能は使わない ◦ Polyfill できないもの(== magic)はだめ ◦ 不足する Low

    Lvl API があるならそれを先に標準化 • 影響は閉じるように進める ◦ モジュールに閉じ、グローバルを汚染しない ◦ Array.prototype への追加などは影響が多いので難しい 25
  15. 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
  16. Adding Websocket support to core #19308 • tl;dr; • こういうことは今後起こり続ける

    • 「シンプルに保つ」vs「進化し続ける」 • 考え方は同じなのでは? 28
  17. 30

  18. 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
  19. まとめ • LAPIs ◦ まだ始まったばかりの提案 ◦ Low Level API が一定の成果を出したからこそ

    ◦ High Level API にも目を向けるには良い時期かも • 方針 ◦ opt-in で global を汚さない ◦ pollyfill への fallback ◦ magic は使わない ◦ 漸進的な解決策 • 課題 ◦ premature-polyfill はどうするのか? ◦ Node でも上手くいかないか? • いろんな意味で今後に期待 33
  20. Feature detection LAPIs itself <script type="module"> (async () => {

    let layeredAPIsSupported = false; try { await import("std:blank"); layeredAPIsSupported = true; } catch {} if (!layeredAPIsSupported) { // Load polyfills the old-fashioned way. } })(); 35