search

markusstraub / radlkarte

Hand-crafted routing information for cyclists
https://www.radlkarte.at
Apache License 2.0
24 stars 9 forks source link

Browser caching of the geojson files #48

Open yyxcv opened 2 months ago

yyxcv commented 2 months ago

Currently the .geojson files are not versioned (eg. with a hash in the filename) and are delivered to the browser without caching headers. That means that browsers are caching the files as they see fit.

screenshot

$.getJSON() calls go through the browser cache. On my phone (Safari) I had to delete the browser cache because the new radlkarte-linz.geojson was not pulled from the server after one day (instead the old file was delivered from the browser cache).

There are several possible options to solve or mitigate the problem:

  1. add hashes to the .geojson filenames and set the caching headers for the .geojson files eg. to 1 year. The hashes would require some form of a build step (eg. using webpack).

  2. adding caching headers on the server side (eg. using .htaccess), so that .geojson files are fetched by browsers regularly (eg. every 6h).

  3. adding a caching buster (=parameter) to the $.getJSON() call, so that the file is fetched at every x hours (or every time if we use a timestamp)

Option 1 would provide the best performance (but would mean the most changes to the project), options 2-3 would mitigate the problem. I would at least implement option 2 or 3.

What are your thoughts on that? I could provide a PR for any of the 3 options.

markusstraub commented 2 months ago

Good catch!

I don't have a strong opinion on the proposed solutions. For solution 2 we need to check if Apache is used? If you have experience I would say whatever you think is most elegant/ effective.

By the way: do you know why even force reloading with e.g. Ctrl F5 does not work for the geojson?

yyxcv commented 2 months ago

Yes, the .htaccess would be the config file for Apache (according to the headers www.radlkarte.at is served from an Apache). If needed, we could also provide the config options for nginx.

If an url contains an anchor (like #wien), and the page is refreshed, the resources are not reloaded but the site jumps to that anchor (that can be a bit annoying if you are developing). Maybe this is also the case if you press Ctrl F5?

OK, I'll look into it what solution would be fitting best for us and create a PR (may take a while).

markusstraub commented 2 months ago

After thinking about it a bit more - I think an easy solution would be to adjust https://github.com/markusstraub/radlkarte/blob/main/data/prepare_geojson.py so that it

  1. renames the geojson to be processed so that it has gets a new name (I imagine radlkarte--.geojson
  2. replaces the mentions in the .html file (e.g. with a regex)

What do you think?

yyxcv commented 2 months ago

Yes that is the same thing the bundler would do.

The downside with using prepare_geojson.py is, that the result of the script gets checked in. We would have to check in different named geojson-files (no diffs anymore) and that the index.html file would change in the repo after every change to a geojson-file.

I have started implementing solution 1 using vite (https://vitejs.dev/) and I like the the result so far. We get some additional benefits when we use a bundler:

I hope my time allows me to give you a PR next weekend. Just have a look at it and tell me what you think.

yyxcv commented 2 months ago

Hi, just created PR #50 .

Let me know if you can work with that setup and what you think about it.

I'm happy to provide updates to the PR if you want to see some changes (or if you find some errors).

I think it would be a good step forward, especially regarding the readability of the js code. (we do not need to stuff everything in a global object -> the bundler makes shure we do not pollute the global namespace. and we split the code into multiple files.)

The only thing contributors would have to do is one call to 'yarn install' (to fetch vite). We would have to inform them before we merge the PR.