mrzorawar/connecto

1. Project shape

- This is a Next.js App Router application for video conferencing.

- The architecture is split into three major areas: auth routes, authenticated dashboard routes, and meeting-room routes.

2. Route and layout boundaries

- src/app/layout.tsx is the top-level shell for the whole app.

- src/app/(auth) contains Clerk-driven sign-in and sign-up pages.

- src/app/(root) contains the authenticated product UI, including dashboard and meeting pages.

- src/app/(root)/layout.tsx and src/app/(root)/dashboard/(home)/layout.tsx provide nested layout boundaries for the private app sections.

3. Authentication boundary

- Authentication is handled by Clerk.

- The route structure with sign-in/[[...sign-in]] and sign-up/[[...sign-up]] is a strong signal that Clerk owns the auth UI and routing.

- src/middleware.ts is the app’s route guard, enforcing that private routes stay behind auth and that unauthenticated users are sent to login flows.

4. Video provider boundary

- src/providers/StreamClientProvider.tsx is the central integration point for Stream Video SDK.

- This provider likely initializes the Stream client using the authenticated user identity and makes the client available to meeting components.

- This keeps Stream setup out of page components and creates a clean boundary between app state and real-time call infrastructure.

5. Server-side Stream token flow

- src/actions/stream.actions.ts is the backend-facing trust boundary for Stream.

- The presence of a dedicated action file suggests the app generates or fetches Stream auth/token data server-side rather than exposing secrets to the browser.

- This is the main data path for secure meeting access: user logs in via Clerk, then the app obtains Stream credentials through a server action.

6. Dashboard subsystem

- The dashboard lives under src/app/(root)/dashboard/(home).

- It includes separate pages for home, personal room, upcoming meetings, and recordings.

- This area is the “meeting management” subsystem: it does not host live calls, but surfaces meeting metadata and user-facing entry points.

7. Meeting subsystem

- src/app/(root)/meeting/[id]/page.tsx is the live meeting entry point.

- The [id] route parameter is the meeting-room identifier, which ties the URL directly to a Stream call/room.

- Components like MeetingRoom, MeetingSetup, MeetingModal, and EndCallButton indicate the lifecycle: create/join, configure devices, run the call, then end it.

8. Meeting data access

- src/hooks/useGetCalls.ts and src/hooks/useGetCallById.ts are the main data-fetching hooks for call history and individual meetings.

- These hooks likely power the dashboard lists and meeting detail views, keeping fetch logic separate from presentation components.

- src/components/CallList.tsx, MeetingCard.tsx, and src/components/new/RecordingCard.tsx are UI consumers of that data.

9. UI composition

- The UI is built from a mix of custom components and ShadCN primitives in src/components/ui.

- Feature-level components such as Navbar, MobileNav, HomeCard, MeetingTypeList, and the new/ folder components suggest a reusable, compositional design system for both dashboard and marketing-style pages.

- The app uses Tailwind and ShadCN as the primary presentation layer.

10. Cross-cutting state and feedback

- Toast/alert infrastructure exists in src/components/Alert.tsx, src/components/ui/toast.tsx, src/components/ui/toaster.tsx, and src/hooks/use-toast.ts.

- src/components/Loader.tsx handles async/loading states.

- These are shared cross-cutting concerns used across auth, dashboard, and meeting flows.

11. Static/config layer

- src/constants/constants.ts, src/lib/utils.ts, and src/lib/mockdata.ts hold shared configuration, helpers, and fallback data.

- components.json, tailwind.config.ts, postcss.config.mjs, and eslint.config.mjs define UI/tooling conventions rather than runtime behavior.

12. End-to-end runtime flow

- A user enters through the auth routes, is protected by middleware, lands in the dashboard, then either creates/join a meeting or opens a historical meeting record.

- When joining a live call, the app uses the Stream provider and server action/token path to enter a room identified by the URL or selected call metadata.

- Stream handles the actual real-time media transport; the app’s responsibility is session orchestration, meeting lifecycle UI, and history/recording surfacing.

13. External services that shape the architecture

- Clerk is the identity system and route gatekeeper.

- Stream Video is the real-time media backend and meeting-state source.

- Vercel is the intended deployment target, which fits the App Router + server actions model.

14. Diagramming takeaway

- The clearest architecture diagram should show three zones: public/auth pages, authenticated dashboard, and live meeting room.

- Connect them through two core backend integrations: Clerk for identity and Stream for call/session execution.

- Put middleware on the route edge, StreamClientProvider around the client runtime, and stream.actions.ts on the secure server boundary.