Server Routes & Resilience — Series 2

Preview — 3 of 10 questions

Why does this pattern work correctly during SSR, but need special handling to work at all on the client?

javascript

// composables/useAuthedFetch.ts
export function useAuthedFetch(url: string) {
  const headers = import.meta.server ? useRequestHeaders(['cookie']) : {}
  return useFetch(url, { headers })
}

AuseRequestHeaders reads headers from the incoming request Nuxt's server is currently handling — during SSR, this lets server-side code forward the original browser's cookies (or other headers) onward to an internal API call, preserving the user's session; on the client, there is no "incoming request" for the running page — the browser's own fetch/$fetch calls already automatically include the browser's cookies for same-origin requests, so useRequestHeaders correctly returns nothing meaningful there and the guard avoids calling it in a context where it has nothing to read

BuseRequestHeaders works identically on server and client — the import.meta.server check in this code is unnecessary and has no effect

CuseRequestHeaders mutates the outgoing response's headers — it has nothing to do with reading incoming request data

DuseRequestHeaders is a client-only composable that throws an error if called during SSR — the guard shown is backwards

How does <NuxtClientFallback> differ from <ClientOnly> when a component inside it throws an error during hydration?

javascript

<template>
  <NuxtClientFallback fallback-tag="div">
    <FlakyThirdPartyWidget />
    <template #fallback>
      <p>Widget unavailable right now.</p>
    </template>
  </NuxtClientFallback>
</template>

A<NuxtClientFallback> and <ClientOnly> are exact synonyms with different names — there's no behavioral difference between them

B<NuxtClientFallback> disables SSR for the entire page it's used on, not just its own slot content

C<NuxtClientFallback> only works with native HTML elements — it can't wrap a custom Vue component

D<NuxtClientFallback> renders its content server-side as normal (unlike <ClientOnly>, which skips SSR for its slot entirely); if the wrapped content then fails to hydrate correctly on the client (throws during hydration), it gracefully falls back to rendering the #fallback slot instead of leaving a broken/blank widget or crashing the surrounding page — <ClientOnly> has no equivalent hydration-failure recovery, since it never attempts server rendering for its slot in the first place

Why does storing a computed value with useStorage inside a Nitro server route persist it across separate incoming requests, unlike a plain module-level variable?

javascript

// server/api/expensive-report.get.ts
export default defineEventHandler(async (event) => {
  const storage = useStorage('cache')
  const cached = await storage.getItem('report')
  if (cached) return cached

  const report = await computeExpensiveReport() // slow
  await storage.setItem('report', report, { ttl: 300 })
  return report
})

AuseStorage and a plain module-level let cached = null variable behave identically in every deployment target — the example shown is unnecessarily complex

BuseStorage provides a key-value storage abstraction (backed by an in-memory driver by default, or a real external driver like Redis/Cloudflare KV when configured) that's designed to work consistently across Nitro's different deployment targets — including serverless/edge platforms where each request may be handled by a completely separate, short-lived process with no shared memory; a plain module-level variable only reliably persists across requests on a traditional long-running Node.js server, and silently fails to share state at all on a platform where each invocation starts fresh

CuseStorage only works when deployed to Node.js — it throws immediately on serverless/edge targets

DuseStorage is purely an in-memory cache with no way to configure a real external backing store like Redis

Answer all 10 questions (7 more), see explanations for every answer, and track your score.