Nitro Server Architecture: Security Proxy Layer & Performance Engine

The Invisible Shield: Full API Proxy

In traditional Headless CMS setups, the frontend calls the WordPress REST API directly — meaning your backend URL is visible in every visitor's browser Network panel. This project takes a fundamentally different approach — the Nitro server mediates all external communication:

The browser only ever sees /api/graphql — never wp-admin or wp-json. This is a fundamental security upgrade.

Auth Isolation: JWT Never Touches the Frontend

After login, WordPress issues a JWT token stored in server-side cookies only. The frontend code never accesses this token:

const token = getCookie(event, 'salong_auth_token')
headers['Authorization'] = `Bearer ${token}`

The frontend only knows "I'm logged in" — the token is completely invisible to JavaScript. Even if the site is compromised by XSS, the attacker cannot steal authentication credentials.

GraphQL Cache Engine: Three-Layer Defense

Layer 1: SHA-256 Response Cache. Every public query result is SHA-256 hashed and stored in Nitro Storage with configurable TTL (default 120s). All requests within the TTL window hit cache directly — zero WordPress load.

Layer 2: In-Flight Request Deduplication. When cache misses, if 100 users simultaneously request the same data, a traditional architecture fires 100 requests at WordPress. Here, createInFlightRequestPool merges concurrent requests into a single upstream call — the other 99 "hitch a ride."

Layer 3: LRU Cache Budget Control. Caching isn't unlimited. cache-budget.mjs implements LRU eviction — when entries exceed 500 or total bytes exceed 32MB, the least-recently-used entries are automatically evicted.

Request Resilience: Auto-Retry & Non-Critical Degradation

request-resilience.mjs provides two tools:

• runWithRetry: For critical requests (page data), auto-retries on 429 errors with exponential backoff. Default: 1 retry, 150ms base delay.
• runNonCriticalAsync: For non-critical requests (sidebar widgets), uses preset fallback data on 429 without blocking page render.

Error Security: Stack Traces Never Leaked

All proxy endpoints use normalizeApiError uniformly:

export function normalizeApiError(err, fallbackMessage, fallbackStatusCode) {
    const statusCode = getStatusCode(err) ?? fallbackStatusCode
    const msg = String(getMessage(err) || fallbackMessage)
    return createError({ statusCode, statusMessage: msg })
}

Users see only clean HTTP status codes and brief messages. No server stack traces, WordPress internal errors, or database connection strings ever reach the frontend.

Sitemap: Dynamic Generation with Smart Caching

// Normal access: 10min browser cache, 1hr CDN, stale-while-revalidate 24hr
'Cache-Control': 'public, max-age=600, s-maxage=3600, stale-while-revalidate=86400'
// Manual refresh (?refresh=1): bypass all caches
'Cache-Control': 'no-store, no-cache, must-revalidate, max-age=0'

Nitro Build Optimization

nitro: {
    minify: true,
    compressPublicAssets: { gzip: true, brotli: true },
    routeRules: {
        '/_nuxt/**': { isr: 600, headers: { 'Cache-Control': 'max-age=31536000, immutable' } }
    }
}

• minify: true — server code minification reduces cold start time
• gzip + brotli — dual compression reduces static asset transfer by 70%
• isr: 600 — ISR caches Nuxt assets for 10 minutes
• immutable — permanent cache for hashed assets, auto-invalidated on update

Summary

This Nitro server architecture protects the WordPress backend with three lines of defense:

1. Access Isolation: All API requests proxied, backend URL never exposed
2. Auth Isolation: JWT tokens in server cookies only, invisible to frontend
3. Information Isolation: Error messages uniformly filtered, stack traces never leaked

Simultaneously, SHA-256 caching, in-flight deduplication, LRU budget control, and intelligent retry minimize WordPress load without sacrificing reliability. It's a true "invisible shield" — users never perceive its existence, but every millisecond of performance and every bit of security is guaranteed by it.