Possibility to configure TTL for file system

[MauriceArikoglu]

When using a cache handler with useFileSystem set to true the handler falls back to serving content from the disk. Is there a possibility to set a TTL for file system data? How can I control the duration of serving from cache and still use the file system cache (we need to because of pages router vercel/next.js#58094)

[better-salmon]

Hi @MauriceArikoglu! I've been thinking about this feature since the beginning of the year. It's a complicated task because the revalidation period information is not stored in cache values that are saved in the file system. However, this feature is vital and will be the next big thing before we release version 1.0.0.

It is recommended to avoid using TTL features with Pages Router. Instead, use the Key Eviction feature if Redis is used as a cache store. The LRU strategy is the recommended approach.

One hack could help, but I must test it first. Please stay tuned for updates on this discussion.

Thank you very much for using the library and providing feedback!

[MauriceArikoglu]

Are you available for discussion on this topic via discord / slack / call?

[better-salmon]

Maybe tomorrow (28.01.2024) via Discord call? But I must warn you that Grammarly hasn't yet created an app for the human brain. I speak English slowly and sometimes forget or misuse words 😆

[better-salmon]

I've created a Discord server https://discord.gg/ZJtHDaXD. @MauriceArikoglu you are welcome!

[better-salmon]

@MauriceArikoglu I've found that you can use arbitrary revalidate values in Pages Router's getStaticProps function.

This code works:

export async function getStaticProps() {
    const result = await fetch('...');

    const parsedResult = await result.json();

    return {
        props: {
            // ...
        },
        revalidate: parsedResult.revalidateValueFromBackend,
    };
}

Even if it is not a common setup, we can not fully rely on parsing source files with the getStaticProps function.

[MauriceArikoglu]

@better-salmon I've tried to come up with a scenario where this is used but couldn't find some.

I propose to solve this by allowing to configure a "fallback" revalidation period and logging explicitly where the revalidation value comes from ("using parsed revalidation", "using fallback revalidation"...).

Also I would offer to write some documentation that explains the feature and it's caveats. What do you think?

[MauriceArikoglu]

@better-salmon actually, looking at the code in #313 we are parsing the values into the Manifest. We could show the result to the user and even allow providing fallback for routes where no value was found.

I would propose the simple solution first and see if the use case really exists.