Nitro et le pattern BFF

Nuxt embarque un vrai serveur

Le dossier server/ est un backend complet (Nitro) : routes API par convention de fichiers, middlewares, accès aux secrets — qui ne quittent jamais le serveur :

// server/api/learn/[...path].ts  (le VRAI fichier de cette plateforme)
export default defineEventHandler(async (event) => {
  const client = event.context.logtoClient          // session posée par le middleware
  const token = await client?.getAccessToken(RESOURCE)  // le JWT, côté serveur SEULEMENT
  if (!token) throw createError({ statusCode: 401 })
  return proxyRequest(event, `${config.learnApiUrl}/v1/${path}`, {
    headers: { authorization: `Bearer ${token}` },
  })
})

Le pattern BFF (Backend For Frontend)

Le navigateur ne parle jamais directement à l'API métier — il parle au serveur Nuxt, qui proxifie :

navigateur ──cookie httpOnly──> Nitro (session, secrets, token) ──Bearer JWT──> API métier

Les quatre gains, tous mesurables :

1. sécurité : le token JWT n'existe que côté serveur — pas de token en localStorage à voler (XSS), un cookie httpOnly que JS ne peut pas lire ;
2. pas de CORS : le navigateur ne voit qu'une seule origine ;
3. façade adaptée : le BFF peut agréger/adapter les appels pour SON front ;
4. secrets serveur : clés d'API, secrets Logto — dans le runtime Nitro, jamais dans le bundle client.

C'est le pattern des deux projets que tu connais : cette plateforme (Nitro → learn-api Rust) et le copilot (Nitro → FastAPI). Quand tu vois runtimeConfig sans préfixe public, c'est du secret serveur ; avec public., c'est embarqué dans le bundle — la frontière la plus importante du fichier de config.

Les usages au-delà du proxy

Routes server = tout ce qui doit être fait près du serveur : gérer la session (le middleware Logto), servir un sitemap, recevoir un webhook, cacher une réponse (cachedEventHandler)… Nitro se déploie partout (node, serverless, edge) — c'est lui le node .output/server/index.mjs de nos Dockerfiles.