improve: tune parameters

api/_utils.ts

@@ -1259,14 +1259,17 @@ export function sendResponse(
   response: VercelResponse,
   body: Record<string, unknown>,
   statusCode = 200,
-  cache?: number
+  cacheSeconds = 300,
+  staleWhileRevalidateSeconds?: number
 ) {
-  // We only want to cache if the status code is 200 and the
-  // caching time has been defined.
-  if (statusCode === 200 && sdk.utils.isDefined(cache)) {
+  if (cacheSeconds > 0) {
+    // Per Vercel's documentation, Vercel will only cache a response when
+    // the status code is 200. I.e. we can always set a cache policy
     response.setHeader(
       "Cache-Control",
-      `s-max-age=${cache}, stale-while-revalidate=${cache}`
+      (staleWhileRevalidateSeconds ?? 0) > 0
+        ? `s-maxage=${cacheSeconds}, stale-while-revalidate=${staleWhileRevalidateSeconds}`
+        : `s-maxage=${cacheSeconds}`
     );
   }
   return response.status(statusCode).json(body);

api/limits.ts

@@ -226,17 +226,14 @@ const handler = async (
         liquidReserves
       ).toString(),
     };
-
-    // Instruct Vercel to cache limit data for this token for 5 minutes. Caching can be used to limit number of
-    // Vercel invocations and run time for this serverless function and trades off potential inaccuracy in times of
-    // high volume. "max-age=0" instructs browsers not to cache, while s-maxage instructs Vercel edge caching
-    // to cache the responses and invalidate when deployments update.
     logger.debug({
       at: "Limits",
       message: "Response data",
       responseJson,
     });
-    sendResponse(response, responseJson, 200, 300);
+    // Respond with a 200 status code and 4 minutes of cache cache with
+    // a minute of stale-while-revalidate.
+    sendResponse(response, responseJson, 200, 240, 60);
   } catch (error: unknown) {
     return handleErrorCondition("limits", response, logger, error);
   }