Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
web over layered apis
Search
Jxck
April 27, 2018
Technology
1.7k
3
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
web over layered apis
web over layered apis (LAPIs) at #tng30
Jxck
April 27, 2018
More Decks by Jxck
See All by Jxck
IE Graduation (IE の功績を讃える)
jxck
22
17k
IE Graduation Certificate
jxck
6
6.3k
RFC 9111: HTTP Caching
jxck
1
830
tc39_study_2
jxck
1
14k
IETF における ABNF とプロトコルパーサの話 / ABNF for Protocol Parser @ IETF
jxck
2
1.3k
Web Components 元年 v3 / Web Components first year v3
jxck
1
1.2k
Periodic Background Sync
jxck
0
670
Podcast over PWA
jxck
1
380
Yearly Web 2019
jxck
0
260
Other Decks in Technology
See All in Technology
【データ横丁主催】AI Agentがコンテキストを使って仕事をした後、何が残るのか― 組織の経験を次の判断に引き継ぐ「Agent Memory」
shisyu_gaku
2
320
データ品質を壊しながらSnowflakeのAIに分析させてみた
kawanago
0
420
私の推しは「聞いてから進む」AIです -AI-DLCに一人でアプリを作らせた話
yama3133
1
160
Meet AgentCore Identity Consent Portal
hironobuiga
3
170
顧客の成果創出とプロダクトの成長を 両立するためのFDE
sansantech
PRO
0
630
企業の現実世界をグラフで写し取る
sansantech
PRO
0
250
プラットフォームを「作る」、 チームに「入り込む」
sansantech
PRO
0
550
雪かき部 #7 もう怖くない!SELECT文!
foursue
0
270
【Findyテック文化祭ワークショップ】新卒エンジニア&採用担当と作る、 なりたい姿と今やるべき一歩
dip_tech
PRO
0
150
Argo CDとAtlantisで実現するインフラ管理のセルフサービス化──小規模SREチームで支えるプラットフォーム
cassius7
0
280
あなたの知らないAmazon VPC Route Server/Amazon VPC Route Server you don't know about
masakiokuda
2
210
認知負荷を吸収し、プロダクトをまたぐPR Preview基盤の設計事例
taiki45
2
570
Featured
See All Featured
[SF Ruby Conf 2025] Rails X
palkan
3
1.4k
Kristin Tynski - Automating Marketing Tasks With AI
techseoconnect
PRO
0
530
Agile that works and the tools we love
rasmusluckow
331
22k
Rebuilding a faster, lazier Slack
samanthasiow
85
9.7k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
254
22k
How to build a perfect <img>
jonoalderson
1
6.1k
Utilizing Notion as your number one productivity tool
mfonobong
4
610
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
Embracing the Ebb and Flow
colly
88
5.2k
Hiding What from Whom? A Critical Review of the History of Programming languages for Music
tomoyanonymous
3
1.3k
The agentic SEO stack - context over prompts
schlessera
0
950
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
31
3.4k
Transcript
Layerd APIs (LAPIs) #tng30 2018/4/27 Jxck
Extensible Web 2
3
4 Low Level APIs • Encoding • URL • Fetch
• Stream • Custom Elem • etc, etc, etc
5 High Low ExtensibleWeb Scope Out of Scope Do It
Yourself
Async Local Storage 6
Storage APIs 7 Window • IndexedDB • CacheStorage • LocalStorage
ServiceWorker • IndexedDB • CacheStorage
Storage APIs 8 Window • IndexedDB • CacheStorage • LocalStorage
ServiceWorker • IndexedDB • CacheStorage Sync API not Allowed async async sync async async
missing point • version とか flag のような少量のデータもある • それを保存するのにも IndexedDB
。。。 • window 側にも Async API は欲しいし • 原因が Sync なら Async API の可能性があっても 良いのでは? • それなら Cache API は AsyncLocalStorage の 特化 API と見ることができる。 • そもそも突然出てきた Cache API の特異さ 9
Propose Async Storage 10 提案、というか「考えてみてもいいの ではないか?」という提案の手前の提 案を discorse に投げてみる。 https://discourse.wicg.io/t/asynclocalstorage/1554
Propose Async Storage 11 • それ localForage でできるよ • それ
lovefield でできるよ • それ IndexedDB でできるよ • それ etc, etc, etc 知ってた!!! https://discourse.wicg.io/t/asynclocalstorage/1554
1 year later 12
13 !!?
14
15
https://docs.google.com/document/d/1VbU4z7xtU_kzuLAcj38KKL5qoOr2UYNUJW8vZB2AcWc/edit 16
17 https://docs.google.com/presentation/d/1_5EVAiuragdEqop8V9b1hJkOW38y4EsXYgNBKdpSHmA
18 Layered APIs
19 課題 • High Lvl API は Out of Scope
だったが ◦ 読み込むアセット(library) の量は増え続ける ◦ High Lvl とはいえコモンケースはあるのでは? ◦ 無視し続けて良いのか? ◦ 「シンプルに保つ」vs「進化し続ける」 • Low Lvl API が軌道に乗った今 ◦ この基盤を安全に拡張し High Lvl API も考えたい ◦ 策定コスト、安全性、互換性なども考慮したい ◦ うまくいけばネイティブ実装していけるのでは
Layered APIs (LAPIs) • Low Lvl API をベースに High Lvl
API を実装 ◦ とはいえ FW ほど高くはない ◦ 多くのユースケースで共通して使われてるもの ◦ ネットワークコスト/パフォーマンス向上 • 標準化プロセスは他の API と基本同じ ◦ 特別扱いはしない • Polyfill をうまく使い漸進的に進める ◦ フォールバックのために import を拡張 ◦ Ship されたら polyfill を fetch しないで済む 20
21 High Low Extensible Scope LAPIs Scope
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>
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 する必要すらなくなる。
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
基本方針 • ブラウザが外に出してない機能は使わない ◦ Polyfill できないもの(== magic)はだめ ◦ 不足する Low
Lvl API があるならそれを先に標準化 • 影響は閉じるように進める ◦ モジュールに閉じ、グローバルを汚染しない ◦ Array.prototype への追加などは影響が多いので難しい 25
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
In Node.js 27
Adding Websocket support to core #19308 • tl;dr; • こういうことは今後起こり続ける
• 「シンプルに保つ」vs「進化し続ける」 • 考え方は同じなのでは? 28
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 !?
30
懸念 31
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
まとめ • LAPIs ◦ まだ始まったばかりの提案 ◦ Low Level API が一定の成果を出したからこそ
◦ High Level API にも目を向けるには良い時期かも • 方針 ◦ opt-in で global を汚さない ◦ pollyfill への fallback ◦ magic は使わない ◦ 漸進的な解決策 • 課題 ◦ premature-polyfill はどうするのか? ◦ Node でも上手くいかないか? • いろんな意味で今後に期待 33
Jack thanks
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