- From: Jeffrey Posnick <notifications@github.com>
- Date: Fri, 14 Dec 2018 21:56:56 +0000 (UTC)
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/ServiceWorker/issues/1373/447490989@github.com>
> But these could arrive much later. Some of the things in the main proposal may also be considered "v2". I can see developers eagerly adopting this approach if browsers started to implement it. Being able to string together complex routing rules with network/cache interactions without the overhead of starting up a service worker or pulling in extra runtime code (except for the polyfill scenario...) would be a nice performance win. I have something of a meta-question about the longer term, v2+, plans though. There are some common concerns that production web apps need to think about, like cache maintenance/expiration policies for runtime caches. Today, that type of activity is likely to happen inside of a `fetch` handler. If we move to a model where you can either get a) fast routing/response generation, but no `fetch` handler or b) the ability to run code to deal with housekeeping, but incur the overhead of a `fetch` handler developers might feel conflicted about that tradeoff. One approach could be to create a new type of event that's fired after a response has been generated by the native router, like `routingcomplete`, that allows developers to run their own bookkeeping code outside of the critical response generation flow. Looking at it from a slightly different perspective, this proposal ends up creating a native implementation of a subset of things that have up until now been accomplished using service worker runtime libraries. Cache-expiration also falls into the category of things that developers commonly accomplish via service worker runtime libraries. The feeling I got from https://github.com/w3c/ServiceWorker/issues/863 is that there hasn't been an appetite for natively implementing that as part of the Cache Storage API. If this routing proposal moves forward, does that change the equation around natively implementing higher-level functionality like cache expiration? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/ServiceWorker/issues/1373#issuecomment-447490989
Received on Friday, 14 December 2018 21:57:19 UTC