Service Worker Travel Log - Day 5
Day 5 - She's so Fetching
In our previous post we used the Fetch API in a Service Worker to log the URLs of all navigational requests to a log table. If you are unfamiliar with the Fetch API it is the replacement used in modern browsers for the XMLHttpRequest API to make network requests. XMLHttpRequest is also the underlying mechanism that older libraries like jQuery use to form their AJAX requests. However, XMLHttpRequest will slowly fade out of usage in browsers and cannot be used in Service Workers. Within Service Workers network requests are exclusively made through the Fetch API and for good reason.
Along with the Fetch API come objects that represent Requests, Responses, Headers, Bodys and Caches which gives developers complete control over how network requests are detected, managed and responded to. With Service Workers it is possible to (1) detect any network request and allow it to respond normally or to (2) substitute or (3) modify the response. It is even possible to respond with a previously cached copy of a response thus allowing an application to operate offline. It will take time for these concepts to be fully appreciated as browsers have never had these capabilities before and they are extremely powerful.
This humorous video highlights the fact that Service Workers along with the Fetch API give you complete control over the network and is worth watching to drive these points home:
Service Worker Game Changer (skip to 1 minute 15 secondes)
https://www.youtube.com/watch?v=wl3kKBw-MGk&feature=youtu.be&t=1m15s
We also need to mention that Service Workers are asynchronous in nature and make extensive usage of Promises. What this means in practical terms is that Service Workers listen and respond to Domain Events. In between Domain Events, Service Workers do not consume resources and merely sit around waiting to spring into action when a Domain Event occurs.
A nice way to visualize the situation is that a Service Worker once installed sits between your visual browser display and the Server you are accessing
You can think of Service Workers as a Network Proxy implemented in JavaScript that use the Fetch API to to manage network requests to the Server and have complete control over the requests and responses.
Next Up: Day 6 - Can You Sub For Me Tomorrow?
In our previous post we used the Fetch API in a Service Worker to log the URLs of all navigational requests to a log table. If you are unfamiliar with the Fetch API it is the replacement used in modern browsers for the XMLHttpRequest API to make network requests. XMLHttpRequest is also the underlying mechanism that older libraries like jQuery use to form their AJAX requests. However, XMLHttpRequest will slowly fade out of usage in browsers and cannot be used in Service Workers. Within Service Workers network requests are exclusively made through the Fetch API and for good reason.
Along with the Fetch API come objects that represent Requests, Responses, Headers, Bodys and Caches which gives developers complete control over how network requests are detected, managed and responded to. With Service Workers it is possible to (1) detect any network request and allow it to respond normally or to (2) substitute or (3) modify the response. It is even possible to respond with a previously cached copy of a response thus allowing an application to operate offline. It will take time for these concepts to be fully appreciated as browsers have never had these capabilities before and they are extremely powerful.
This humorous video highlights the fact that Service Workers along with the Fetch API give you complete control over the network and is worth watching to drive these points home:
Service Worker Game Changer (skip to 1 minute 15 secondes)
https://www.youtube.com/watch?v=wl3kKBw-MGk&feature=youtu.be&t=1m15s
We also need to mention that Service Workers are asynchronous in nature and make extensive usage of Promises. What this means in practical terms is that Service Workers listen and respond to Domain Events. In between Domain Events, Service Workers do not consume resources and merely sit around waiting to spring into action when a Domain Event occurs.
A nice way to visualize the situation is that a Service Worker once installed sits between your visual browser display and the Server you are accessing
You can think of Service Workers as a Network Proxy implemented in JavaScript that use the Fetch API to to manage network requests to the Server and have complete control over the requests and responses.
Next Up: Day 6 - Can You Sub For Me Tomorrow?