j-goyal/google-oauth-nextjs

1. This is a Next.js App Router frontend, not a standalone backend. The repository is organized around route-based UI screens under src/app, with shared layout, guards, and feature components supporting auth-protected pages.

2. The primary routes suggest an authentication and admin portal:

- public/entry paths: /, /sign-in, /callback

- protected app paths: /dashboard, /sessions

- admin-only paths: /admin/users

- access control/error paths: /403 and not-found

3. The top-level UI shell lives in src/app/layout.tsx and src/app/globals.css. Shared chrome is split into reusable pieces like Header, Footer, ProfileDropdown, and GlobalLoader, indicating the app uses a consistent app frame with loading and user-state awareness.

4. Authentication is a first-class subsystem. ClientAuthProvider, AuthLayout, SignInButton, and ManageAuth.module.ts point to a login/session bootstrap flow. The presence of src/app/callback/page.tsx and types/auth/GoogleAuthRequest.ts suggests an OAuth-style sign-in callback, likely Google-based, with frontend handling of the redirect completion step.

5. Authorization is enforced in the client UI via guard components rather than only by route structure. RoleGuard, AdminOnly, and SuperAdminOnly indicate role-based access control, while 403 is the explicit access-denied destination. utils/roleUtils.ts and constants/userRoles.ts centralize role logic so multiple screens can share the same rules.

6. The app has a clear admin management subsystem under src/components/admin and src/app/admin/users. This includes:

- listing users (AdminGetAllUsersContent)

- changing roles (UserRoleDropdown)

- inspecting user sessions (UserSessionsModal)

This is the main operational/admin surface of the product.

7. Session visibility is a separate domain, not just part of login. src/app/sessions/page.tsx, constants/userSessions.ts, types/sessions/*, utils/sessionUtils.ts, and ManageMe.module.ts suggest the UI can fetch and render current or historical sessions for the signed-in user, and admins can inspect sessions per user.

8. Data access is centralized in a service layer rather than being scattered through components. src/services/ManageAuth.module.ts, ManageMe.module.ts, and ManageUsers.module.ts are the feature-specific API boundaries. These likely wrap calls to an external identity/user management backend through a shared HTTP client.

9. The HTTP layer is abstracted in src/lib/axios.ts and src/lib/AxiosMethods.ts. This is the core integration point between the frontend and the backend API, and it likely handles request configuration, interceptors, and method helpers consistently across auth, user, and session endpoints.

10. State management is split into small global stores:

- useAuthStore for authenticated user/session state

- useGlobalLoader for app-wide loading state

This implies the UI reacts to auth transitions and network activity globally, not just within individual pages.

11. Shared UI primitives live in src/components/ui and appear to be a local design system layer. Components such as button, input, select, table, pagination, and data-table are reused by higher-level features. components.json suggests these primitives may be generated or styled via a component system like shadcn/ui.

12. Loading and skeleton states are intentionally separated from the main content. GlobalLoader handles app-level waiting states, while src/components/shimmer/* contains page-specific skeletons for the dashboard, header, access-denied view, and grid layouts. This indicates asynchronous data fetching is expected across multiple screens.

13. Error handling is normalized through utilities like getErrorMessage and isGloballyHandledError. That suggests the service layer and UI share a common pattern for translating API failures into user-facing messages, with some errors suppressed from duplicate handling.

14. Types and constants are split into domain-focused folders (types/auth, types/users, types/sessions, constants/*). This keeps user, auth, and session data contracts explicit and helps the architecture stay aligned with the backend API shape.

15. At a high level, the data flow is: route page mounts -> auth/client provider establishes current user -> guards decide access -> feature page calls a service module -> service uses the axios layer -> response populates stores/components -> UI renders tables, dropdowns, modals, or redirects to sign-in/403 as needed. The architecture is a client-heavy, role-aware admin portal with clear separation between routing, authorization, service access, and shared presentation.