QUICKSTART: alt-fetch section improvements

merge-requests/12/merge
Michał 'rysiek' Woźniak 2022-03-11 16:54:13 +00:00
rodzic 2e261e3ce8
commit f5f72e6acf
1 zmienionych plików z 12 dodań i 6 usunięć

Wyświetl plik

@ -25,7 +25,7 @@ We are going to assume a simple website, consisting of:
In fact, this hypothetical website is very similar to (and only a bit simpler than) [Resilient.Is](https://resilient.is/), the homepage of this project. For the purpose of this tutorial, we will assume we are hosting our website on [`example.org`](https://en.wikipedia.org/wiki/Example.org) as the primary original domain.
## First steps
## 1. First steps
We shall start with a completely minimal (but not really useful) deployment of LibResilient, and then gradually add functionality.
@ -95,7 +95,7 @@ Each user of our website, after visiting any of the HTML pages, will now have th
This doesn't yet provide any interesting functionality, though. So how about we do that next.
## Adding cache
## 2. Adding cache
Bare minimum would be to add offline cache to our website. This would at least allow our visitors to continue to browse content they've already loaded once even if they are offline or if our site is down for whatever reason.
@ -176,7 +176,7 @@ Next time that same visitor loads that particular resource, it will be served fr
For the time being, let's keep using the `fetch`-then-`cache` option, though.
## Alternative transport
## 3. Alternative transport
We have a working Service Worker, we have it configured to retrieve content using the standard HTTPS fetch, and we made sure that successful requests are stashed for later use (using the `cache` stashing plugin). This makes it possible for our visitors to access content they have already accessed, even if our website is unavailable for whatever reason.
@ -231,8 +231,14 @@ And the `config.json` file contains:
}
```
The `alt-fetch` plugin *requires* the `endpoints` configuration key. That key contains, you guessed it, endpoints to try to retrieve the content from. And yes, there can be many of them — we will use that later on!
The `alt-fetch` plugin *requires* the `endpoints` configuration key. That key contains, you guessed it, endpoints to try to retrieve the content from. There can be many of them — we will use that later on — but for now we are only going to define one.
We need to also make sure that our content is available `https://example.gitlab.io/`. LibResilient can't really help with that, it's up to the website administrator to make sure that content ends up where it needs to be for LibResilient to be able to access and retrieve it.
Once our website content is available on both `https://example.org/` *and* `https://example.gitlab.io/`, this configuration finally makes it possible to provide new content to visitors of our site, who have visited it at least once before, *even if the main domain is down, blocked, or unavailable for any other reason*.
From the perspective of the visitor, the site will work normally, some content (that is, content that has not been stashed locally yet) will just be slower to retrieve. How much slower depends on the exact way our site is unavailable, and the value of `defaultPluginTimeout`:
- if the `example.org` server is rejecting connections, or there are TLS certificate problems, or such, the `fetch` plugin will fail instantenously, and the `cache` and then `alt-fetch` plugins will kick in quickly;
- if the `example.org` server is overloaded and takes seconds to respond, or for whatever reason the IP packets are and never responed to, LibResilient will give the `fetch` plugin `defaultPluginTimeout` (in our case, 1s) and then will move to trying `cache`, and `alt-fetch` afterwards.
For now, we need to also make sure that our content ends up also on `https://example.gitlab.io/`. That's on you, LibResilient can't really help with that. It's up to the website administrator to make sure that content ends up where it needs to be for LibResilient to be able to access and retrieve it.
If our website content is available on both `https://example.org/` *and* `https://example.gitlab.io/`, this configuration finally makes it possible to provide content to visitors of our site, who have visited it at least once, *even if the main domain is down*.