How to cache results from API calls when building SSG pages? Traditional in-memory memoization doesn't seem to work #13765
-
|
I'm fetching the Airtable API 3 times per page, and I'm building around ~30 pages, which generates about 100 API calls when building the site on Vercel. I tried implementing a basic in-memory cache system (memoization), but while it does work locally (unit tested), it doesn't work when the site is being build. Here is the cache implementation: It relies on treating the file But it obviously don't work neither on Vercel, neither locally when running Am I missing something? I believe pages are built in a special way that resets the cache between each page. (as logged above, the cache seems to be filled with |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 6 replies
-
|
We may need an example to show how to do this 🤔 You could create a build time only file that stores the data and read from that file instead of repeating the request, we do something like that for our docs. In our docs we fetch the latest tag of the repo to get the manifest of routes, and because that can happen once per documentation page, we cache the result in a file (build time only) to avoid being rate limited: import path from 'path';
import { readFile, writeFile } from '../fs-utils';
import { GITHUB_API_URL, REPO_NAME } from './constants';
const USE_CACHE = process.env.USE_CACHE === 'true';
const TAG_CACHE_PATH = path.resolve('.github-latest-tag');
export async function getLatestTag() {
let cachedTag;
if (USE_CACHE) {
try {
cachedTag = await readFile(TAG_CACHE_PATH, 'utf8');
} catch (error) {
// A cached file is not required
}
}
if (!cachedTag) {
const res = await fetch(`${GITHUB_API_URL}/repos/${REPO_NAME}/releases/latest`);
if (res.ok) {
const data = await res.json();
const tag = data.tag_name;
if (USE_CACHE) {
try {
await writeFile(TAG_CACHE_PATH, tag, 'utf8');
} catch (error) {
// A cached file is not required
}
}
cachedTag = tag;
}
}
return cachedTag;
}(You can also check the above file in our repo) We then set module.exports = {
webpack: (config, { dev, isServer }) => {
if (!dev && isServer) {
// we're in build mode so enable shared caching for the GitHub API
process.env.USE_CACHE = 'true';
}
return config;
}
}(You can also check the above file in our repo) And include the generated cache file ( |
Beta Was this translation helpful? Give feedback.
-
|
Error handling can be improved there. This example goes to our site and it works well there, if it doesn't return a tag our docs fail at build time. A public implementation won't be this simple so feel free to improve it 👍 . Keep in mind this is only intended for build time, this caching is not intended to be used at runtime where the environment may not even allow you to write or access shared cache files. |
Beta Was this translation helpful? Give feedback.
-
|
But, if I do that on Vercel, will it work? At build time, obviously (but it's still using the file system, AFAIK) |
Beta Was this translation helpful? Give feedback.
-
|
At build time yes, our docs deploy to Vercel 👍 |
Beta Was this translation helpful? Give feedback.
-
|
@lfades Thanks again for your help, I managed to write a re-usable hybrid memory/disk cache storage for this. Went from 140 API calls to half a dozen:
Implementation: Check the NRN repository below to see the git tree at time of writing: Check PR: /**
* Hybrid cache, can use in-memory storage or on-disk storage.
*
* You can select the kind of storage you want through the options.
*
* Algorithm:
* - Check if cache exist for key, if not then call the dataResolver and cache the result.
* - If cache exists and record age is lower than TTL (default: 30 seconds), then return cached data. Otherwise, call the dataResolver and cache the result.
*
* Special considerations:
* - If options.ttl is 0, then TTL is disabled and data will live indefinitely
* - Memory cache storage is selected by default
* - Memory cache storage will not work if you want to cache data at build time, when building the pages (typically: SSG). You must use the disk for this kind of usage.
* - Disk cache storage works on Vercel, you need a writable file system
*
* @example With default (in-memory, TTL 30 secs)
* const stuff = await hybridCache('CustomerTable', async () => await fetchMyStuff());
*
* @example Using disk storage with no TTL, meant to cache stuff once for all pages during server initial build (for SSG, typically - IS_SERVER_INITIAL_BUILD comes from next.config.js)
* const stuff = await hybridCache('CustomerTable', async () => await fetchMyStuff(), { enabled: !!process.env.IS_SERVER_INITIAL_BUILD && process.env.NODE_ENV !== 'development', storage: {type: 'disk', options: {filename: 'my-stuff'}} });
*
* @param keyResolver string | Function Key used to store the data in the cache
* @param dataResolver Function Has to be implemented by the caller and is supposed to take care of fetching the data
* @param options HybridCacheOptions
*/
const hybridCache = async <T>(keyResolver: string | (() => string), dataResolver: () => T, options: Partial<HybridCacheOptions> = defaultHybridCacheOptions): Promise<T> => {
const { ttl, enabled, storage } = deepmerge(defaultHybridCacheOptions, options);
if (!enabled) { // Bypasses cache completely
// eslint-disable-next-line no-console
console.debug('Cache is disabled, bypassing');
return dataResolver();
}
let cacheStorage: HybridCacheStorage;
let storageOptions: StorageOptions = {};
if (storage.type === 'memory') {
cacheStorage = require('./memoryCacheStorage');
} else {
cacheStorage = require('./diskCacheStorage');
const { options } = storage;
storageOptions = options;
}
let key: string;
if (typeof keyResolver === 'function') {
key = keyResolver();
} else {
key = keyResolver;
}
const cachedItem: CachedItem = await cacheStorage.get(key, storageOptions);
if (typeof cachedItem !== 'undefined') {
const { value, timestamp } = cachedItem;
if (timestamp === 0 || getTimestampsElapsedTime(timestamp, +new Date()) < ttl) {
return value;
} else {
logger.debug('Cache key has expired');
}
} else {
logger.debug('Cache key does not exist');
}
const unMemoizedResult: T = await dataResolver();
return cacheStorage.set(key, unMemoizedResult, storageOptions);
}; |
Beta Was this translation helpful? Give feedback.
-
|
@lfades Thanks for your example, I was able to build a caching system for my app. Just wanted to point out that your links are broken and I tried looking around for the files but couldn't find anything like next-site in your repos. |
Beta Was this translation helpful? Give feedback.
-
|
The Next.js docs now describe a solution to this problem using React's
So does Next.js presently recommend using a React Canary release and |
Beta Was this translation helpful? Give feedback.
We may need an example to show how to do this 🤔
You could create a build time only file that stores the data and read from that file instead of repeating the request, we do something like that for our docs. In our docs we fetch the latest tag of the repo to get the manifest of routes, and because that can happen once per documentation page, we cache the result in a file (build time only) to avoid being rate limited: