Updates for differential serving.#121
Conversation
aomarks
changed the title
aomarks
changed the title
| <html lang="en"> | ||
| <head> | ||
| <meta charset="utf-8"> | ||
| <base href="/"> |
There was a problem hiding this comment.
Worth noting that base can be set once per document. Its usage is typically considered esoteric, but we will be co-opting it for our purposes, possibly to the exclusion of someone else's.
There was a problem hiding this comment.
Good point. It's useful enough for this case, though, that I'm OK with usurping it. If someone has a different need for <base>, I think it's reasonable to put the onus on them to come up with a different scheme for differential serving.
| // Register service worker if supported. | ||
| if ('serviceWorker' in navigator) { | ||
| navigator.serviceWorker.register('/service-worker.js'); | ||
| navigator.serviceWorker.register('service-worker.js', {scope: '/'}); |
There was a problem hiding this comment.
How does setting base in a document affect resource loading in a service worker? Suppose I have customized the service worker so that I can A/B test a specific component by redirecting requests for it to one of two candidate implementations. Will I need to be aware of the base configuration in order to correctly load the candidate implementation that has been chosen?
There was a problem hiding this comment.
Good question, @cdata . In our proposed scheme for multiple builds / differential serving, each individual build has its own service worker, presumably partially auto-generated by the build process (as is the case with our toolchain).
There is a small bit of server- or network-resident logic in this scheme that chooses one of the individual builds based on the visiting user agent, and based on that logic the service worker associated with that build is the one that gets registered.
In theory, any special SW logic you had for specific purposes would be essentially unaffected by our build-switching scheme; it would just need to find its way into each of the individual service workers in the final file layout.
Thoughts?
| on-iron-form-response="_didReceiveResponse" | ||
| on-iron-form-presubmit="_willSendRequest"> | ||
| <form method="post" action="/data/sample_success_response.json"> | ||
| <form method="post" action="data/sample_success_response.json"> |
There was a problem hiding this comment.
This is an interesting example. IRL, this API probably won't be static, and probably will live at a fixed location even though the client relies on differential serving. If I naively follow a "best practice" of never using absolute URLs for things (so as to take advantage of differential serving), it may be difficult to reason about the correctness of changes like this (which, again IRL, could actually be a bug). The base, in this case, creates a dissonance between the URLs for static resources and non-static ones (unless my server already fixes this for me in a magical way).
There was a problem hiding this comment.
Agree, SHOP is not very representative here. Also agree there's a bit of nuance needed in explaining which URLs need to be relative to work in this scheme -- essentially it's URLs to static resources on the primary hosting server. URLs for navigating to "virtual routes" should still be expressed as absolute from the server root, and of course URLs referring to resources on other hosts will remain absolute.
|
Merging! (Talked with keanulee/frankiefu offline). Thanks for the discussion. The other point keanulee brought up is that with this pattern we're duplicating static assets (images etc.) in multiple build directories, which is not ideal in terms of deploy size on disk, and also caching. It's conceivable that different builds would actually have different static files (e.g. higher image compression for a mobile build), but otherwise you would just use absolute URLs for shared assets, and lift them up a directory as a post-build step. That's something we could eventually add to the polymer tooling. |
3 participants
We want to demonstrate differential serving using shop as an example where we serve a different build (e.g. bundled/unbundled) to different user agents based on their capabilities (e.g. push).
The strategy we have settled on (cc @graynorton) is to switch the entrypoint we serve depending on user agent, where each entrypoint has a
<base>tag pointing to its build sub-directory, so that we can then use relative links to point at the right static resources.So, this PR updates shop to use relative links for static resources, and adds a default
<base href="/">tag (which we will automatically update frompolymer build) so that the app behaves exactly as before when served from the root.It also sets the service worker scope to
/so that (in conjunction with aService-Worker-Allowedheader), service workers served from a build's sub-directory can intercept requests from all routes.