Skip to content

Avoid checking for new languages for each request

The boot method calls storeAvailableIntroLanguages for every request, which :

  • checks for files on disk
  • makes two writes in the database (deleteAppValue, setAppValue)

This is not efficient.

There's different leads to improve this.

Simplest

Do not try to detect language changes. Require people that add new languages to change the configkey themselves.

occ config:app:set intros introsLanguages --value="en,fr,it"

Obviously I thought of that after writing the rest…but it's still interesting.

Easy

Instead of calling deleteAppValue and setAppValue each time, simply use getAppValue to check that the new $availableLanguages is different from the one in the database. Only call setAppValue when it's being changed.

Medium

Use a local cache https://docs.nextcloud.com/server/latest/developer_manual/basics/caching.html with a TTL to store available languages, fallback to looking on disk for new things when TTL is reached.

Harder/long-term

For starters, adding extra data files to the source tree in the install isn't really a good idea, though easy to handle at first :

  1. It prevents Nextcloud code integrity check to run (optional), as there will be extra files
  2. Each time the app is updated, the files need to be added back
  3. You need to have this kind of check to make it work

Instead, data such as these should be stored either in a big text field in the database or as a file in the appdata folder, using proper Nextcloud APIs to handle cases where the whole filesystem is on s3. This will need however a proper way to "upload" data to those destination, either a simple occ command or a fully featured UI in the admin settings. This will also change the way translations are called, instead of directly calling them, you'll need a controller that handles fetching the data from its source, probably with some cache for the data here as well, since there will be a significant overhead to fetch data this way. However, there will no longer be any need to check for new translation files at each request, as the list of languages will be saved locally.

Also, this whole thing should be more efficient if we can check if an intro is disabled for an user before fetching it, see #16 (closed)