Frontend Configuration

Source Structure#

src/
├─ app/
│  ├─ (auth)/         # /login /register /forgot-password /reset-password /verify-otp
│  ├─ (dashboard)/    # /dashboard + settings sub-pages
│  ├─ admin/          # /admin user management
│  ├─ auth/verify-otp/ # OTP entry page (email + Google sign-in)
│  ├─ auth/callback/  # legacy OAuth landing page
│  ├─ (marketing)/    # landing pages (Navbar shown)
│  └─ (docs)/docs/    # this documentation portal
├─ components/       # ui/ primitives, layout, docs/, providers/
├─ context/          # LanguageContext (en|mm in localStorage)
├─ store/            # Redux Toolkit: store/index.ts + store/api/*
└─ lib/              # translations, utils, docs data

API Proxy (next.config.ts)#

async rewrites() {
  const apiBase = process.env.NEXT_PUBLIC_API_URL || "http://localhost:5000";
  return [{ source: "/api/v1/:path*", destination: `${apiBase}/:path*` }];
}

Read it carefully: the proxy STRIPS the /api/v1 prefix and re-attaches whatever :path* matched. Therefore NEXT_PUBLIC_API_URL must INCLUDE /api/v1, like http://localhost:5000/api/v1 — the destination becomes …/api/v1/:path* only because the variable carries the prefix. This single detail is the #1 integration gotcha: requests would 404 without it and the Google button would miss too.

Redux Toolkit Query Layout#

const baseQuery = fetchBaseQuery({
  baseUrl: "/api/v1",
  credentials: "include",
  prepareHeaders: (headers) => {
    headers.set("Content-Type", "application/json");
    return headers;
  },
});

export const baseApi = createApi({
  reducerPath: "api",
  baseQuery,
  tagTypes: ["User", "Auth", "Admin", "Token"],
  endpoints: () => ({}),
});

baseUrl is a relative path — the browser calls the Next.js server itself, and the rewrite above forwards it to the backend, keeping cookies first-party. credentials: 'include' matters because httpOnly cookies ARE the session. Domain slices inject endpoints into this api: authApi.ts (login/register/logout/refresh/forgot/verify-otp/reset-password/resend), userApi.ts (profile, change-password, deactivate, delete), adminApi.ts (users list, stats, user by id, status update).

import { baseApi } from "@/store/api/baseApi";
import { createApi } from "@reduxjs/toolkit/query/react";

export const authApi = createApi({
  reducerPath: "authApi",
  baseQuery: baseQuery, // reuse the shared baseQuery
  endpoints: (builder) => ({
    login: builder.mutation<AuthResponse, LoginRequest>({
      query: (credentials) => ({ url: "/auth/login", method: "POST", body: credentials }),
    }),
  },
});

Conventions: one file per domain slice under store/api/, an interface per request/response shape, invalidatesTags/providesTags wired with the baseApi tagTypes, mutations for changing state and queries for reads. Hooks are exported as useXxxMutation/useXxxQuery and consumed inside client components.

Theme & Language Infrastructure#

• Theme: next-themes, class strategy; the shared ThemeToggle component is reused everywhere (docs portal included).
• Language: LanguageContext keeps en|mm in localStorage; t("key") resolves from lib/translations.ts. The docs portal has its own hydration-safe docs-locale hook on top of it.
• Navigation refresh trail: email/password login routes straight to /dashboard. Google OAuth goes to /auth/verify-otp first, then /dashboard after the emailed code is accepted.

Integration Facts (what IS connected)#

Verified wired to the backend: auth flows (register/login/logout/refresh/forgot-otp-reset/verify/resend), Google OAuth via the login button, profile management (get/update, change-password, deactivate, delete) and the admin panel (users list with filters, stats, user detail, status update). Screenshot/upload endpoints do not exist yet and no billing flow is wired — the docs mark them clearly as future.