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

fix: caching #75

Merged
merged 1 commit into from
Nov 23, 2023
Merged

fix: caching #75

merged 1 commit into from
Nov 23, 2023

Conversation

flakey5
Copy link
Member

@flakey5 flakey5 commented Nov 15, 2023

See #73

  • Explicit caching strategies (@MattIPv4 's comment)
  • Only cache 2XX responses, and if they're get Requests (explicit cache) (already true)
  • Our default responses (on the constants) should have explicit headers for no-cache/no-store
  • 5XX responses also should not have cache (already true)
  • We should extract many other implicit constants ... to proper constant files

@flakey5 flakey5 force-pushed the flakey5/73 branch 3 times, most recently from a3e3c02 to c53e585 Compare November 21, 2023 01:34
@flakey5 flakey5 linked an issue Nov 21, 2023 that may be closed by this pull request
@flakey5 flakey5 marked this pull request as ready for review November 21, 2023 01:39
@flakey5 flakey5 requested review from a team as code owners November 21, 2023 01:39
src/util.ts Outdated Show resolved Hide resolved
},
});

export const FILE_NOT_FOUND = (request: Request): Response => {
Copy link
Member

Choose a reason for hiding this comment

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

I don't think explicit types are needed here, TS will already infer this is of type Response

Copy link
Member Author

Choose a reason for hiding this comment

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

Maybe, but eslint requires them under @typescript-eslint/explicit-function-return-type

Copy link
Member

@ovflowd ovflowd left a comment

Choose a reason for hiding this comment

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

LGTM, just one question:

Quick question, do we need to also add CACHE_HEADERS.failure to our 5XX responses? (the try/catch on the worker.ts?)

@flakey5
Copy link
Member Author

flakey5 commented Nov 21, 2023

Quick question, do we need to also add CACHE_HEADERS.failure to our 5XX responses? (the try/catch on the worker.ts?)

That is also a part of this pr

@ovflowd
Copy link
Member

ovflowd commented Nov 21, 2023

Quick question, do we need to also add CACHE_HEADERS.failure to our 5XX responses? (the try/catch on the worker.ts?)

That is also a part of this pr

Oh I somehow didnt see this, still not seeing it 🤔 can you point me to the diff?

@flakey5
Copy link
Member Author

flakey5 commented Nov 21, 2023

Oh I somehow didnt see this, still not seeing it 🤔 can you point me to the diff?

https://github.com/nodejs/release-cloudflare-worker/pull/75/files#diff-1245a5bbc4ca0684dff978efcae118b08f62d2afc05812df22d0627985b4273aR51

@flakey5 flakey5 merged commit dc790d4 into main Nov 23, 2023
3 checks passed
@ovflowd ovflowd deleted the flakey5/73 branch November 23, 2023 19:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

We should have default strategies for caching
3 participants