Suitable for template specific PWA/SW?

  • Resolved Anonymous User 18703099

    (@anonymized-18703099)


    2 years, 7 months ago

    Hello!

    We were looking to introduce a Service Worker into an existing site to provide a specific curated collection of resources that could be queued up for caching after some input from the user. This would not involve turning the entire site into a PWA, rather, just a specific template that would provide the UI for this curated collection.

    Would setting the template URL as the entry point suffice here?

    Our hope was that the PWA plugin would provide the foundation for this, but I’m increasingly getting the impression that this may not be the case, and that we will need to spin up a more custom implementation. Is this a fair assumption?

    It’s not immediately clear how we would interface with the front-end service worker to implement our own logic to dictate what is cached, after our JS is registered via wp_front_service_worker.

    Granted there are PHP filters available for this, but we’ll need more dynamic control over what is added to the cache, and when.

    Do you have any examples, JS specifically, of custom Service Worker implementations using the plugin? Is the JS API basically a middleware between WP and Workbox?

    Thanks,
    Dave

    • This topic was modified 2 years, 7 months ago by Anonymous User 18703099.
    • This topic was modified 2 years, 7 months ago by Anonymous User 18703099.
    • This topic was modified 2 years, 7 months ago by Anonymous User 18703099.
Viewing 8 replies - 1 through 8 (of 8 total)
  • Plugin Author Weston Ruter

    (@westonruter)

    2 years, 7 months ago

    The plugin provides a PHP abstraction for the Workbox JS API, while also allowing you to write JS workbox code and register it via wp_front_service_worker. So let’s say you have some custom JS code that interfaces with workbox (which we alias to wp.serviceWorker), you can include that file in the service worker with code like this:

    add_action(
	'wp_front_service_worker',
	static function( WP_Service_Worker_Scripts $scripts ) {
		$scripts->register(
			'foo',
			[
				'src'  => plugin_dir_url( __FILE__ ) . 'foo.js', // Source.
			]
		);
	}
);

    So yes, this plugin is intended to be a foundation for any custom SW logic, while also providing sensible defaults for 80% of sites (e.g. offline caching).

    For how to write the JS code specifically to interface with Workbox, I would refer to the Workbox docs: https://developers.google.com/web/tools/workbox/

    Thread Starter Anonymous User 18703099

    (@anonymized-18703099)

    2 years, 7 months ago

    Thanks @westonruter, I dived in this morning as I’d already enqueued the JS, but it wasn’t clear how much of the SW lifecycle we needed to implement; from the looks of it we don’t need to do as much, more a case of working out how to make PWA/Workbox work for us with our specific needs. 🙂

    One question I did have was, is it possible for Workbox to still trigger a cache request for a resource that is 302’d from the original URL?

    I’ve registered a custom endpoint to get around the fact that the route registration is regex based — we’re essentially mapping /resources/<post-id> to a number of curated files/posts that live across a number of different permalink structures — however I’m guessing that 302 redirecting to the resource breaks the ability for the SW/Workbox to cache it? Is there a suggested way around this, or do we need to look at returning the actual asset in response to a request for these URLs? e.g. /resource/42 returns 42.pdf rather than redirecting to the media library URL for the PDF.

    Appreciate your efforts on the plugin, fingers crosssed for core merge!

    Plugin Author Weston Ruter

    (@westonruter)

    2 years, 7 months ago

    It sounds like what you need to do is add a route for /resources/<post-id> which does the fetch from origin and then handles any redirect and then puts the result in the cache.

    Maybe you could us the CacheableResponsePlugin to opt-in to 302 status to cache: https://developers.google.com/web/tools/workbox/modules/workbox-cacheable-response#caching_based_on_status_codes

    But then the redirect would be cached, not the resource that it is redirecting to unless you have a caching strategy for the redirected URLs as well.

    I’m not clear on the need for a custom endpoint, however. What’s the problem with it being regex-based?

    Thread Starter Anonymous User 18703099

    (@anonymized-18703099)

    2 years, 7 months ago

    The regex based route registration prevents us from caching assets that live in different URL structures, but also the fact that we don’t want to cast the net so wide that everything is cached.

    For example, it will be a curated selection of *some* but not all PDFs/Office docs as well standard WP posts/standard HTML pages.

    If we could pass in an array of cacheable paths that would solve the issue, but as we have to supply a regex, the endpoint was my idea of having a single canonical URL structure for the assets instead of having to produce a complex regex pattern…but obviously the redirects are now the issue.

    Plugin Author Weston Ruter

    (@westonruter)

    2 years, 6 months ago

    How many paths are you talking about here? While the regex may be complex, you wouldn’t have to construct it by hand. You could just gather the array or paths, and pass each one through preg_quote() and then join the list with |. And that would be the regex.

    Thread Starter Anonymous User 18703099

    (@anonymized-18703099)

    2 years, 6 months ago

    That’s a good shout actually; there’s potentially quite a few but I’m actually tempted to intercept the fetch request and check the requested file against a whitelist of URLs as opposed to using the route regex for now.

    One of the things that did cause a little confusion was that it wasn’t immediately clear that registration of a new route didn’t cover Navigation requests; it might be worth explicitly stating this in the readme?

    Regardless, to work around this I’ve simply opted into Navigation caching, and I’m intercepting the fetch event to only cache the navigation request if it matches our whitelist of URLs, giving us the compartmentilisation wr need. 🙂

    Plugin Author Weston Ruter

    (@westonruter)

    2 years, 6 months ago

    Regardless, to work around this I’ve simply opted into Navigation caching, and I’m intercepting the fetch event to only cache the navigation request if it matches our whitelist of URLs, giving us the compartmentilisation wr need. 🙂

    How did you opt-in to navigation caching?

    One of the things that did cause a little confusion was that it wasn’t immediately clear that registration of a new route didn’t cover Navigation requests; it might be worth explicitly stating this in the readme?

    Perhaps that could be an argument when calling WP_Service_Worker_Caching_Routes::register()

    Thread Starter Anonymous User 18703099

    (@anonymized-18703099)

    2 years, 6 months ago

    Sorry for the delayed reply!

    > How did you opt-in to navigation caching?

    For this I’ve just used wp_service_worker_navigation_caching_strategy

    > Perhaps that could be an argument when calling WP_Service_Worker_Caching_Routes::register()

    That would be fantastic

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘Suitable for template specific PWA/SW?’ is closed to new replies.