ansh-vaish/web-ide

1. Overall shape

- This is a Next.js App Router application with a clear split between public marketing/auth pages, a protected dashboard, and a per-playground editor runtime.

- Most behavior is organized into feature modules under modules/, while app/ primarily defines routes and layout boundaries.

2. Routing and page boundaries

- app/layout.tsx and nested layouts establish the global shell, then route groups separate concerns:

- app/(home) for the landing page

- app/(auth) for sign-in

- app/dashboard for authenticated project management

- app/playground/[id] for the editor workspace

- API routes live under app/api, including auth handlers and a template API.

3. Authentication subsystem

- Auth is handled with NextAuth v5 (auth.ts, auth.config.ts) and Prisma-backed sessions/accounts.

- OAuth providers are implemented in lib/oauth/google.ts and lib/oauth/github.ts.

- The auth UI and helper logic live in modules/auth, including sign-in form, logout/user controls, and a current-user hook.

- middleware.ts and routes.ts enforce public vs protected route behavior, redirecting unauthenticated users to sign-in.

4. Persistence and server data model

- Prisma is the persistence layer (prisma/schema.prisma) and is configured for MongoDB.

- lib/db.ts is the database access boundary used by server code/actions.

- The README indicates the main persisted entities are users/auth records, playgrounds, serialized template/file-tree data, star marks, and chat messages.

5. Dashboard subsystem

- modules/dashboard contains the authenticated project-management experience: project table, empty state, sidebar, add-new/add-repo entry points, star toggles, and a template-selection modal.

- The dashboard page is the control center for creating, duplicating, updating, starring, and deleting playgrounds.

- This layer is likely where server actions are triggered to create or mutate playground records before routing into the editor.

6. Playground editor subsystem

- app/playground/[id] hosts the main coding workspace.

- modules/playground contains the file explorer, editor, dialogs for file/folder CRUD, and loader states.

- The playground feature is state-heavy and is separated into hooks (usePlayground, useFileExplorer) plus utility code for editor config and file-tree serialization.

7. In-browser file system and editor state

- The playground maintains a serialized representation of the project tree and file contents, with operations for add/rename/delete, tab management, per-file save, and save-all.

- modules/playground/lib/path-to-json.ts suggests conversion between a file-path structure and the JSON/tree model used in state and persistence.

- This is the boundary where user edits in the Monaco editor are translated into app state and then into DB writes.

8. Live execution and preview

- modules/web-containers wraps WebContainer-based runtime execution, including container bootstrapping, terminal UI, and preview rendering.

- The container layer is isolated from the editor tree, which lets the app run project code in-browser without relying on a separate backend execution service.

- A transformer hook suggests output/log stream adaptation between container events and the UI.

9. Template and starter-project flow

- app/api/template/[id]/route.ts exposes template data to the app, and lib/template.ts likely centralizes template retrieval/normalization.

- The large starters-main/ directory contains starter projects for multiple frameworks/languages: Angular, Express, Hono, Next.js, React, and Vue.

- These starters are the source material for new playgrounds and explain how the app can initialize different project shapes from templates.

10. Shared UI and design system

- components/ui is a broad shared component library, likely generated around a design system such as shadcn/ui.

- This folder provides the reusable primitives used by auth, dashboard, and playground screens, keeping those features visually consistent.

- lib/utils.ts and hooks/use-mobile.ts support cross-cutting UI behavior.

11. API surface

- The API surface is intentionally small: auth callbacks, error handling, and a template lookup endpoint.

- Most feature mutations appear to be handled through server actions in modules/*/actions, rather than a large custom REST layer.

- That means the main data flow is client interaction -> feature module action -> Prisma -> updated route/state.

12. Deployment and environment

- The presence of .github/workflows/deploy.yml indicates CI/CD automation for deployment.

- Runtime dependencies that materially affect architecture are Next.js/React, NextAuth, Prisma/MongoDB, Monaco Editor, and WebContainer; these define the app’s boundaries between server-rendered routing, persistent storage, and client-side execution.