Are there import caches?
I read somewhere yesterday that workers are initialised during the TLS handshake to basically remove cold starts.
I also read that sometimes isolates are re-used for requests and to not rely on mutable state.
I'm currently playing about with dependency injection and I'm wondering whether it would be beneficial to lazily load "providers" (dynamically import) and cache it in global mutable state, or whether to just import it all upfront. I'm thinking cost-centric.
Thank you!
11 Replies
A given Worker instance exists on a single Cloudflare server, of which there are a lot - a user is never guaranteed to hit the same server, and therefore same Worker, unless they have a connection open with that server (i.e keep-alive).
All the requests being handled by a given Worker share the same global scope, so storing something specific to one request is not advised since other requests will overwrite/read it. That's where AsyncLocalStorage comes in
Since it's so infrequent to hit the same Worker, other than by the same user on the same connection, caching in the global scope isn't that effective.
Thank you for the quick reply! By cache I literally mean just caching the import to not call
import() againWrangler uses
esbuild which bundles it all into one file, effectively removing the import.
If you use --no-bundle then it will upload the JS files separately and let you do dynamic importsYeah I'm writing my own framework compiler with SWC so no esbuild
All this is about is essentially not importing files for routes that haven't been hit
Since the same worker wouldn't be hit again and the cache I would otherwise implement is effectively useless, would it be safe to assume that it's never beneficial to dynamically import?
Dynamic imports help you because during Worker startup, it needs to parse and evaluate the code - which is everything if bundled into one file.
If you do dynamic imports, you can defer that burden until you actually hit the path at runtime.
Prewarm does start during the TLS handshake, but as Workers can now be up to 10 MiB, there is a case for trying to avoid slow cold starts.
Thank you! Seems like I should just allow someone to
export const lazy = true
If you don't mind me reusing the thread - would there be any downside to deploying SSR sites on Workers instead of Pages Functions?Nope - both are Workers
Functions is just an abstraction on top of it - the
onRequest stuff you see is just a template over async fetch(req, env, ctx)Is file-level routing implemented more efficiently for Pages Functions? Or is it in JS?
It's a Wrangler feature - it's all bundled into a single file by esbuild still
Thank you so much for your time! I won't bother you any more lol