Implement the following plan:

Server-Side Data Fetching for Next.js Pages

Goal

Move client-side data fetching to server-side to enable SSR and eliminate loading states on initial page load.

Current Pattern (Problem)

// page.tsx - only checks auth
export default async function Page() {
  const session = await auth.api.getSession({ headers: await headers() });
  if (!session) redirect("/login");
  return <Client />;  // No data passed
}

// client.tsx - fetches data, shows loading state
"use client";
export function Client() {
  const [data, setData] = useState(null);
  const [isLoading, setIsLoading] = useState(true);

  useEffect(() => {
    fetch(apiUrl, { credentials: "include" })
      .then(res => res.json())
      .then(setData);
  }, []);

  if (isLoading) return <Loading />;  // User sees this first
  return <UI data={data} />;
}

Proposed Pattern

// page.tsx - fetches data server-side
export default async function Page() {
  const session = await auth.api.getSession({ headers: await headers() });
  if (!session) redirect("/login");

  const data = await serverApiFetch<Data>("/api/data");
  return <Client fallbackData={data} />;
}

// client.tsx - uses SWR with server data as fallback
"use client";
import useSWR from "swr";

export function Client({ fallbackData }: { fallbackData: Data }) {
  const { data, error, isLoading, mutate } = useSWR<Data>(
    "/api/data",
    fetcher,
    { fallbackData }  // SSR data used immediately, no loading flash
  );

  // After mutations, call mutate() to refresh
  async function handleUpdate() {
    await fetch("/api/data", { method: "POST", ... });
    mutate();  // Revalidate data
  }

  return <UI data={data} onUpdate={handleUpdate} />;
}

Benefits of SWR:

• fallbackData shows SSR content immediately (no loading state on initial render)
• Auto-revalidation on window focus (configurable)
• Manual mutate() after mutations
• Built-in error handling and loading states for revalidation
• Deduplication of concurrent requests

Data Access Strategy: API with Cookie Forwarding

Keep the API server as the single source of truth for data access. Server components forward the user's session cookie to make authenticated API requests.

Why this approach:

• Clean separation of concerns
• API remains the authoritative data layer
• No query duplication between web and API
• Easier to maintain and reason about

Implementation:

• Create serverApiFetch() utility that forwards cookies from incoming request
• Add INTERNAL_API_URL env var for server-to-server communication
• In K8s: http://[local-hostname]:3001
• In dev: Same as NEXT_PUBLIC_API_URL

Pages to Convert

Implementation Plan

Phase 1: Install SWR and Create Utilities

Install SWR:

cd apps/web && bun add swr

Create apps/web/lib/server-api.ts (server-side fetch with cookie forwarding):

import { cookies } from "next/headers";

const INTERNAL_API_URL = process.env.INTERNAL_API_URL || process.env.NEXT_PUBLIC_API_URL;

export async function serverApiFetch<T>(path: string, options?: RequestInit): Promise<T> {
  const cookieStore = await cookies();

  // Forward session cookies to the API
  const cookieHeader = cookieStore.getAll()
    .map((c) => `${c.name}=${c.value}`)
    .join("; ");

  const response = await fetch(`${INTERNAL_API_URL}${path}`, {
    ...options,
    headers: {
      ...options?.headers,
      Cookie: cookieHeader,
    },
  });

  if (!response.ok) {
    throw new Error(`API error: ${response.status} ${response.statusText}`);
  }

  return response.json() as Promise<T>;
}

Create apps/web/lib/swr.ts (client-side SWR configuration):

import { env } from "@/lib/env";

// Fetcher for SWR - uses client-side apiFetch pattern
export const fetcher = async <T>(path: string): Promise<T> => {
  const headers: HeadersInit = {};

  // Include impersonation header if set
  if (typeof window !== "undefined") {
    const impersonateUserId = sessionStorage.getItem("impersonateUserId");
    if (impersonateUserId) {
      headers["X-Impersonate-User"] = impersonateUserId;
    }
  }

  const response = await fetch(`${env.NEXT_PUBLIC_API_URL}${path}`, {
    headers,
    credentials: "include",
  });

  if (!response.ok) {
    throw new Error(`API error: ${response.status}`);
  }

  return response.json() as Promise<T>;
};

Phase 2: Add Environment Variable

Add to .env.development and document in .env.example:

INTERNAL_API_URL=http://localhost:3001

Add to turbo.json globalPassThroughEnv so it's available during build.

Phase 3: Convert Pages One by One

Order:

1. /apply - Simplest (single fetch, user's own data)
2. /review - Admin page, applications list
3. /enrollment - Admin page, applications + enrollments
4. /mail - Admin page, logs + stats

For each page:

1. Update page.tsx to call serverApiFetch() and pass data as fallbackData prop
2. Update client.tsx to use useSWR() with fallbackData option
3. Remove useEffect for initial data load
4. Remove manual isLoading/setData state (SWR handles this)
5. Replace manual refetch logic with mutate() calls after mutations
6. Add error.tsx for error boundary

Phase 4: Testing

• Verify pages render with data immediately (no loading flash)
• Verify mutations still work
• Verify auth redirects still work
• Run e2e tests

Files to Modify

New files:

• apps/web/lib/server-api.ts - Server-side API fetch with cookie forwarding
• apps/web/lib/swr.ts - SWR fetcher and configuration
• apps/web/app/apply/error.tsx - Error boundary
• apps/web/app/review/error.tsx - Error boundary
• apps/web/app/enrollment/error.tsx - Error boundary
• apps/web/app/mail/error.tsx - Error boundary

Modified files:

• apps/web/package.json - Add swr dependency
• .env.development - Add INTERNAL_API_URL
• .env.example - Document INTERNAL_API_URL
• turbo.json - Add INTERNAL_API_URL to globalPassThroughEnv
• apps/web/app/apply/page.tsx - Fetch data server-side
• apps/web/app/apply/client.tsx - Accept initialApplication prop
• apps/web/app/review/page.tsx - Fetch data server-side
• apps/web/app/review/client.tsx - Accept initialApplications prop
• apps/web/app/enrollment/page.tsx - Fetch data server-side
• apps/web/app/enrollment/client.tsx - Accept initialApplications and initialEnrollments props
• apps/web/app/mail/page.tsx - Fetch data server-side
• apps/web/app/mail/client.tsx - Accept initialLogs and initialStats props

Verification

1. bun run tsc - Type check passes
2. bun run dev - Pages load without loading flash
3. bun run test:e2e - E2E tests pass
4. Manual testing: Submit application, review applications, trigger sync

If you need specific details from before exiting plan mode (like exact code snippets, error messages, or content you generated), read the full transcript at: ~/.claude/projects/-Users-challen-www-usingandunderstanding-ai/2125baa0-624c-4bc1-9e21-fc38a5dacef1.jsonl

Ah, yes. Let's also create Zod typechecking for data flowing to and from the API. The API should typecheck responses before send and the client should typecheck them again on receive. Ditto for data moving the other way say via POST.

Actually, sorry. Let's complete the current task first and we'll do this as a separate task.

Read the output file to retrieve the result: [tmp-path]

Wait. Please don't start the dev server in the background that way. It's hard to shut down. Please shut it down and I'll start it in a separate tab.

No, I started it again. Go ahead and proceed with testing.

Are you sure that's the problem? Shouldn't you add logging to find out first?

See above.

No... I think we should use fetch. There must be a workaround.

Is there a way to just disable this during development? The checking?

Done.

Same problem: ⨯ TypeError: fetch failed @repo/web:dev: at async serverApiFetch (lib/server-api.ts:30:20) @repo/web:dev: at async ApplyPage (app/apply/page.tsx:34:27) @repo/web:dev: 28 | const url = ${INTERNAL_API_URL}${path}; @repo/web:dev: 29 | @repo/web:dev: > 30 | const response = await fetch(url, { @repo/web:dev: | ^ @repo/web:dev: 31 | ...options, @repo/web:dev: 32 | headers: { @repo/web:dev: 33 | ...options?.headers, { @repo/web:dev: digest: '3967988472', @repo/web:dev: [cause]: Error: unable to verify the first certificate; if the root CA is installed locally, try running Node.js with --use-system-ca @repo/web:dev: at ignore-listed frames { @repo/web:dev: code: 'UNABLE_TO_VERIFY_LEAF_SIGNATURE' @repo/web:dev: } @repo/web:dev: }

Continue.

I restarted the dev server. Try again.

What should we add to NODE_ENV in .env.development to disable this? (node:73915) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to '0' makes TLS connections and HTTPS requests insecure by disabling certificate verification. (Use node --trace-warnings ... to show where the warning was created)

No, there should be a way to just disable this specific warning. It's log noise in development.

Through something like this added to NODE_OPTIONS: --disable-warning=DEP0040 (that's for a different warning).