Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use permanent cache for translation files on production #181377

Merged
merged 5 commits into from
Apr 24, 2024

Conversation

pgayvallet
Copy link
Contributor

@pgayvallet pgayvallet commented Apr 23, 2024

Summary

Fix #83409

Use a permanent cache (public, max-age=365d, immutable) for translation files when in production (dist), similar to what we're doing for static assets.

Translation files cache busting is a little tricky, because it doesn't only depend on the version (enabling or disabling a custom plugin can change the translations while not changing the build hash), so we're using a custom hash generated from the content of the current translation file (which was already used to generate the etag header previously).

@pgayvallet
Copy link
Contributor Author

/ci

@pgayvallet
Copy link
Contributor Author

/ci

@pgayvallet pgayvallet added Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Project:i18n v8.15.0 release_note:skip Skip the PR/issue when compiling release notes labels Apr 23, 2024
@pgayvallet
Copy link
Contributor Author

/ci

@pgayvallet
Copy link
Contributor Author

/ci

@pgayvallet
Copy link
Contributor Author

/ci

@kibana-ci
Copy link
Collaborator

💛 Build succeeded, but was flaky

Failed CI Steps

Test Failures

  • [job] [logs] FTR Configs #46 / Alerting alerts_as_data install alerts as data resources should install context specific alerts as data resources on startup

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
@kbn/core-i18n-server-internal 8 10 +2
@kbn/core-i18n-server-mocks 3 4 +1
total +3
Unknown metric groups

API count

id before after diff
@kbn/core-i18n-server 3 4 +1
@kbn/core-i18n-server-internal 8 10 +2
@kbn/core-i18n-server-mocks 3 4 +1
total +4

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

Copy link
Contributor Author

@pgayvallet pgayvallet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

self-review

'content-type': 'application/json',
'cache-control': 'must-revalidate',
etag: translationCache.hash,
['/translations/{locale}.json', `/translations/${translationHash}/{locale}.json`].forEach(
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I kept the old route for two reasons:

  • functional tests against the endpoint (it's a pain to retrieve the translation hash from the API integration tests...)
  • BWC: some integrations/customers might be reaching this endpoint, you never know

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This path is not a public API so i dont think we should worry about custom integrations especially since i dont see any use case for this.. Maybe worth creating an issue to remove it later on in a separate PR

Comment on lines +65 to +75
if (isDist) {
headers = {
'content-type': 'application/json',
'cache-control': `public, max-age=${365 * DAY}, immutable`,
};
} else {
headers = {
'content-type': 'application/json',
'cache-control': 'must-revalidate',
etag: translationCache.hash,
};
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I kept the etag cache control for non-distribution build, even if I'm not sure how useful this is, given the translation hash will change when translations are added/removed/changed.

Comment on lines +208 to +210
const translationHash = i18n.getTranslationHash();
const translationsUrl = `${serverBasePath}/translations/${translationHash}/${i18nLib.getLocale()}.json`;

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changing the translationsUrl that will be sent to the browser to load the translations

@pgayvallet pgayvallet marked this pull request as ready for review April 23, 2024 14:02
@pgayvallet pgayvallet requested a review from a team as a code owner April 23, 2024 14:02
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-core (Team:Core)

Copy link
Member

@Bamieh Bamieh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@pgayvallet pgayvallet merged commit 060d99b into elastic:main Apr 24, 2024
17 checks passed
@kibanamachine kibanamachine added the backport:skip This commit does not require backporting label Apr 24, 2024
Copy link
Contributor

@jloleysens jloleysens left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Read through the code, did not test locally but overall lgtm

registerTranslationsRoute({
router,
locale: 'en',
isDist: true,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I may have missed it, but is it worth having a jest integration style test for this "isDist" Boolean and how it affects response headers?

kpatticha pushed a commit to kpatticha/kibana that referenced this pull request Apr 26, 2024
## Summary

Fix elastic#83409

Use a permanent cache (`public, max-age=365d, immutable`) for
translation files when in production (`dist`), similar to what we're
doing for static assets.

Translation files cache busting is a little tricky, because it doesn't
only depend on the version (enabling or disabling a custom plugin can
change the translations while not changing the build hash), so we're
using a custom hash generated from the content of the current
translation file (which was already used to generate the `etag` header
previously).

---------

Co-authored-by: kibanamachine <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting Project:i18n release_note:skip Skip the PR/issue when compiling release notes Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc v8.15.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Use cache-control: max-age instead of etag for /translations route
6 participants