feat: d1 adapter for the tag cache #320

james-elicx · 2025-02-02T22:32:34Z

This PR is stacked on top of the changes in #319.

Enable tag/path revalidation and next/after e2es for app directory example.
Enable passing a function for the tag cache.
D1 adapter for the tag cache, based on the AWS DynamoDB adapter.
Extracts a manifest of build-time tags/paths for use as a fallback instead of pre-populating D1 as IMO there is not a simple way for us to do that.
Adds the env.d.ts file to the tsconfig so that TypeScript recognises env vars defined in there.

Docs PR - opennextjs/docs#66

changeset-bot · 2025-02-02T22:32:37Z

🦋 Changeset detected

Latest commit: 54a89cb

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@opennextjs/cloudflare	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

pkg-pr-new · 2025-02-02T22:33:29Z

Open in Stackblitz

pnpm add https://pkg.pr.new/@opennextjs/cloudflare@320

commit: 54a89cb

conico974 · 2025-02-03T08:19:53Z

packages/cloudflare/src/cli/build/utils/extract-cache-assets-manifest.ts

+ *
+ * The mapping creates an index of each tags pointing to its paths, and each path pointing to its tags.
+ */
+export function extractCacheAssetsManifest(buildOpts: BuildOptions) {


We already compute all the tags and cache in the aws adapter https://github.com/opennextjs/opennextjs-aws/blob/14b81827f9078b98e32115fb5cfe706d03d64537/packages/open-next/src/build/createAssets.ts#L159-L239
BTW you are missing the fetch cache here

Thanks, I didn't realise the manifest was already generated. I'll change it to use that

This is resolved, right?

conico974 · 2025-02-03T08:48:10Z

packages/cloudflare/src/api/d1-tag-cache.ts

+// inlined during build
+const manifest = process.env.__OPENNEXT_CACHE_TAGS_MANIFEST;
+
+class D1TagCache implements TagCache {


I'm not sure that D1 is the right fit for this. The tag cache has been designed around DynamoDB and its strength/limitation.
I'm introducing a new mode for the tag cache that would probably better fit an SQL db opennextjs/opennextjs-aws#717

I think that what would make the most sense would be either using D1 with the new mode (and it avoids having to prepopulate anything) or using this mode with KV (But this would probably mean duplicating some data in KV)

Another thing is that if i'm not mistaken D1 is regional, but the tag cache will be reached from all over the world (And the fetch cache could be used in SSR request as well )

I'm not sure KV would really work that well due to its eventually consistent nature - you get up to 60 seconds on entries continuing to be polled, and if you use a <5 min revalidation time, it essentially becomes pointless trying to use a cache IMO.

D1 is regional yeah - means a little more latency for some regions.

I can rework this PR to be based on the new mode if that makes most sense.

For the new mode there is benefits and drawbacks, one option could be to implement both mode so that each user could use the one that is better suited for them.
@vicb @dario-piotrowicz What do you think about that ? For reference here is the issue explaining the 2 mode and their benefits/drawback opennextjs/opennextjs-aws#706

+1 to have the 2 modes if it's not too much dev & maintenance vs the benefits.

We can also merge a single mode when it's ready and implement the other mode later.

examples/e2e/app-router/open-next.config.ts

packages/cloudflare/src/api/d1-tag-cache.ts

vicb · 2025-02-07T07:46:29Z

packages/cloudflare/src/api/d1-tag-cache.ts

+
+    try {
+      const { success, results } = await db
+        .prepare(`SELECT tag FROM ${table} WHERE path = ?`)


can't we use bind for the table name? (SQL injection)

Unfortunately not - it gives a syntax error. The table is driven by an env var, so i wouldnt think sql injection will be a problem

It should not... but maybe we can hardcode tags here anyway.

I did this with the idea that people might want to use a different table name (multiple projects using same db), so it was using the env var and defaulting to tags if not present. I can change to always hardcode to tags if you want, but I feel like it's a useful bit of configurability to have?

packages/cloudflare/src/api/d1-tag-cache.ts

vicb · 2025-02-07T07:59:31Z

packages/cloudflare/src/cli/build/bundle-server.ts

@@ -112,6 +113,7 @@ export async function bundleServer(buildOpts: BuildOptions): Promise<void> {
      "process.env.NEXT_RUNTIME": '"nodejs"',
      "process.env.NODE_ENV": '"production"',
      "process.env.NEXT_MINIMAL": "true",
+      "process.env.__OPENNEXT_CACHE_TAGS_MANIFEST": `${JSON.stringify(extractCacheAssetsManifest(buildOpts))}`,


@conico974 do you think this could be added to the config adapter?

You mean the open-next.config.ts ? Not sure how it would work since it is bundled before next build

One thing about inlining the manifest here is that this could become pretty big, especially for website with a lot of page.
For example the __NT_/layout tag is on every page.
Inlining this will likely become an issue at scale

I was thinking about adapter/config but the size issue would be the same.

So we should preload the DB?

Would it be possible to generate a SQL file instead and run wrangler execute as part of the deployment ? This seems like a better idea
Or maybe using the rest API with the initialization function from OpenNext

packages/cloudflare/src/api/d1-tag-cache.ts

conico974 · 2025-02-07T12:26:30Z

packages/cloudflare/src/cli/build/utils/extract-cache-assets-manifest.ts

+ * The mapping creates an index of each tags pointing to its paths, and each path pointing to its tags.
+ */
+export function extractCacheAssetsManifest(options: BuildOptions): CacheAssetsManifest {
+  // TODO: Expose the function for getting this data as an adapter-agnostic utility in AWS.


That's kind of the point of the initializationFunction https://opennext.js.org/aws/inner_workings/components/initializer
With a custom wrapper and a custom tag cache it could be turned into a function.
Not entirely sure it's worth it though

james-elicx force-pushed the james/tag-cache branch from 01d1c68 to d0d0738 Compare February 2, 2025 22:33

james-elicx linked an issue Feb 2, 2025 that may be closed by this pull request

Cache support #105

Open

james-elicx force-pushed the james/tag-cache branch from d0d0738 to 1cce4af Compare February 2, 2025 22:42

james-elicx marked this pull request as ready for review February 2, 2025 22:44

james-elicx requested review from vicb, conico974 and dario-piotrowicz February 2, 2025 22:44

james-elicx mentioned this pull request Feb 2, 2025

Cache support #105

Open

conico974 reviewed Feb 3, 2025

View reviewed changes

james-elicx force-pushed the james/tag-cache branch 3 times, most recently from 401843a to 69f2d20 Compare February 5, 2025 22:11

james-elicx force-pushed the james/isr branch 2 times, most recently from 229b2e2 to fa3b420 Compare February 6, 2025 22:08

james-elicx force-pushed the james/tag-cache branch from 69f2d20 to 3566d04 Compare February 6, 2025 22:15