fix: add stale-while-revalidate to limits #906
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
| * @param cache The cache time in seconds - defaults to 300 | ||
| * @returns The response object | ||
| */ | ||
| export function sendResponse( |
There was a problem hiding this comment.
The logic in this function is essentially copied/pasted throughout the codebase. I think it would make sense to centralize this as the redundancy makes it error-prone.
There was a problem hiding this comment.
Nice. Is it worth setting some defaults on the input arguments? statusCode might be one where we could default to 200 right?
ACX-1692 Look into occasional timeout in limits/suggested-fees
Occasionally we are receiving a timeout of longer than the 3 second requirement we expect from We can find some improvements by limiting the number of calls we make internally in these endpoints to other |
| statusCode: number, | ||
| cacheSeconds: number, | ||
| staleWhileRevalidateSeconds: number |
There was a problem hiding this comment.
It might be nice if these were part of an object so they could be set by name, rather than inferred by order. Then you could probably nuke the comment as well.
We should add
stale-while-revalidateto our caching policy. The UX is improved by not requiring an unlucky user to request a fresh, uncached response.Additionally, we have boilerplate on all endpoints to return a response. We should centralize our returned headers. This PR adds a small response function that is tested in limits.
Requirements Fulfilled:
/limitsis not more than 5 minutesPartially closes ACX-1692