Caching issue in frontend with Docker image #1718

New Issue

jonastheis · 2020-04-19T10:19:08Z

jonastheis commented

2020-04-19 10:19:08 +00:00

When running the Docker image to serve the frontend against any instance e.g. self-hosted or https://try.vikunja.io/api/v1/ there is a caching issue. Disabling the service workers leads to expected behaviour where the new tasks are fetched and correctly displayed when e.g. selecting another list and coming back to the list where the tasks were created.

I attached an example as a gif. The frontend is running locally with Docker and points to https://try.vikunja.io/api/v1/. As can be seen creating tasks, switching to another list, coming back to the initial list leads to the tasks not displayed. Only another round of selecting another list or refreshing the page does lead to the expected behaviour.

When running the Docker image to serve the frontend against any instance e.g. self-hosted or https://try.vikunja.io/api/v1/ there is a caching issue. Disabling the service workers leads to expected behaviour where the new tasks are fetched and correctly displayed when e.g. selecting another list and coming back to the list where the tasks were created. I attached an example as a gif. The frontend is running locally with Docker and points to https://try.vikunja.io/api/v1/. As can be seen creating tasks, switching to another list, coming back to the initial list leads to the tasks not displayed. Only another round of selecting another list or refreshing the page does lead to the expected behaviour.

Untitled.2020-04-19 12_14_00.gif

284 KiB

konrad commented

2020-04-19 12:41:43 +00:00

The service worker is set up so that it won't cache api routes. Does this only happen when self-hosting? Does it make api requests and are they served by the service worker or the api? (You can verify this by looking at the network tab in the developer tools).

Service workers only work with https which means if you're running locally without https, they should not be activated at all. There is a logging output in the browser console if the service worker has been registered, can you verify that?

Does this also happen with other browsers like Firefox or Chrome? I'm using Vikunja daily and have never seen that, but I'm using Firefox or Chrome occasionally. Maybe this is a Safari issue...

The service worker is set up so that it won't cache api routes. Does this only happen when self-hosting? Does it make api requests and are they served by the service worker or the api? (You can verify this by looking at the network tab in the developer tools). Service workers [only work with https](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers#Setting_up_to_play_with_service_workers) which means if you're running locally without https, they should not be activated at all. There is a logging output in the browser console if the service worker has been registered, can you verify that? Does this also happen with other browsers like Firefox or Chrome? I'm using Vikunja daily and have never seen that, but I'm using Firefox or Chrome occasionally. Maybe this is a Safari issue...

jonastheis commented

2020-04-19 13:37:46 +00:00

Setup:

every browser I tested. Chrome, Safari, Brave
locally hosted frontend with Docker container pointing to https://try.vikunja.io/api/v1/ backend
works as expected when I disable the service worker (as can be seen at the end of gif)

Setup: - every browser I tested. Chrome, Safari, Brave - locally hosted frontend with Docker container pointing to https://try.vikunja.io/api/v1/ backend - works as expected when I disable the service worker (as can be seen at the end of gif)

Untitled.2020-04-19 15_36_24.gif

755 KiB

konrad added the

kind/bug

label 2020-04-19 17:31:39 +00:00

konrad commented

2020-05-09 17:00:39 +00:00

Hmm how did you point the frontend to try.vikunja.io?

jonastheis commented

2020-05-10 05:16:11 +00:00

Building the container myself with the VIKUNJA_API_BASE_URL adjusted.

echo '{"VIKUNJA_API_BASE_URL": "https://try.vikunja.io/api/v1/"}' > public/config.json

docker build -t jonastheis/vikunja-frontend .

docker run jonastheis/vikunja-frontend:latest

Building the container myself with the `VIKUNJA_API_BASE_URL` adjusted. ``` echo '{"VIKUNJA_API_BASE_URL": "https://try.vikunja.io/api/v1/"}' > public/config.json docker build -t jonastheis/vikunja-frontend . docker run jonastheis/vikunja-frontend:latest ```

konrad commented

2020-05-10 16:13:39 +00:00

I've pushed an update with a possible fix, could you test again?
I'm not really sure why a) this does not work and b) I didn't saw this yet "in the wild". Do you get the same issues when running the api locally/on the same host?
Even if the api requests appear to go through the service worker in the dev tools, it could be they are still directly requested instead of served from the cache in the service worker.

Also note the api url is now configurable, no need to rebuild.

I've [pushed an update](https://kolaente.dev/vikunja/frontend/commit/f524a3efc1eeb31e56a5639d7e606301126bb7ff) with a possible fix, could you test again? I'm not really sure why a) this does not work and b) I didn't saw this yet "in the wild". Do you get the same issues when running the api locally/on the same host? Even if the api requests appear to go through the service worker in the dev tools, it could be they are still directly requested instead of served from the cache in the service worker. Also note [the api url is now configurable](https://vikunja.io/docs/install-frontend/#api-url-configuration-in-docker), no need to rebuild.

konrad commented

2020-05-10 16:19:43 +00:00

It seems like the way caching routes with workbox works the regexes for external hosts only work if matched from the start, which means including the full domain + protocol. (We have different rules per route in place to determine if a request should be served from cache or not. These include one to exclude api routes from caching)

We only match api routes by checking if the url contains api/v1/ and nothing else - while this works well for urls served at the same host, it won't match if the api sits on a different host - instead the default fallback route matching, which matches every route and enables caching for them is used.

Hmmmm I guess that would explain it, but I'm not sure how to solve this.

It seems like the way caching routes with workbox works the regexes for external hosts only work [if matched from the start](https://developers.google.com/web/tools/workbox/modules/workbox-routing#how_to_register_a_regular_expression_route), which means including the full domain + protocol. (We have different rules per route in place to determine if a request should be served from cache or not. These include one to exclude api routes from caching) We only match api routes by checking if the url contains `api/v1/` and nothing else - while this works well for urls served at the same host, it won't match if the api sits on a different host - instead the default fallback route matching, which matches every route and enables caching for them is used. Hmmmm I guess that would explain it, but I'm not sure how to solve this.

konrad commented

2020-07-04 16:59:21 +00:00

I've pushed an update in e66c8bf6b3 to only explicitly cache assets, hopefully that helps with wrongly caching api requests.

I've pushed an update in https://kolaente.dev/vikunja/frontend/commit/e66c8bf6b3a8c5098d107af0cb199375bd7e9ff2 to only explicitly cache assets, hopefully that helps with wrongly caching api requests.

jonastheis commented

2020-08-09 16:58:13 +00:00

I've just tested 2c21fd430c and it works like a breeze. Thanks!

Maybe add the option to provide a custom VIKUNJA_API_URL via environment variable somewhere to the docs? I couldn't find it there but and just had a quick look at the code but I guess would be nice to have that documented!

I've just tested 2c21fd430c and it works like a breeze. Thanks! Maybe add the option to provide a custom `VIKUNJA_API_URL` via environment variable somewhere to the docs? I couldn't find it there but and just had a quick look at the code but I guess would be nice to have that documented!

jonastheis closed this issue

2020-08-09 16:58:13 +00:00

konrad commented

2020-08-09 20:17:56 +00:00

There is an env variable to set the api url in the docker container but since the frontend itself is completely static, it is not possible to put this in the frontend by default. It works only in docker since I can put a script there which handles replacing the api url in the index.html file with the one from the env variable.

Do you think the linked docs are enough to document it?

There is an env variable to set the api url [in the docker container](https://vikunja.io/docs/install-frontend/#api-url-configuration-in-docker) but since the frontend itself is completely static, it is not possible to put this in the frontend by default. It works only in docker since I can put a script there which handles replacing the api url in the `index.html` file with the one from the env variable. Do you think the linked docs are enough to document it?

jonastheis commented

2020-08-10 06:52:30 +00:00

Yeah that seems sufficient. Great work!

konrad referenced this issue from a commit

2024-02-07 14:00:33 +00:00

chore(deps): update dependency vitest to v0.7.11 (#1718)

Sign in to join this conversation.