manish-qw/meet-scribe

1. System shape

- Meet Scribe is a two-tier app: a React/Vite frontend and a FastAPI backend.

- The backend is not just an API; it also owns the meeting bot runtime, real-time transcript streaming, and AI summarization pipeline.

2. Frontend boundary

- frontend/src is the presentation layer: landing/login/dashboard/meeting pages plus reusable UI components.

- src/lib/api.ts is the HTTP client boundary to the backend.

- src/hooks/useMeetingSocket.ts is the real-time boundary for live meeting updates.

- src/lib/firebase.ts and useAuth.ts show the frontend relies on Firebase Auth for user identity/session state.

3. User-facing flows

- The main user path is: sign in → submit a Google Meet link → monitor live transcript/status → view summary/dashboard history.

- ProtectedRoute.tsx indicates authenticated access gates around dashboard/meeting views.

- DashboardPage, MeetingPage, and LandingPage reflect a split between marketing, authenticated workspace, and live session UI.

4. Backend API layer

- backend/app/api/routes/auth.py and meetings.py expose the HTTP endpoints.

- This layer likely handles login/token validation, meeting creation/history lookup, and returning persisted meeting artifacts.

- backend/app/core/dependencies.py and config.py centralize request-scoped wiring and environment-driven configuration.

5. Real-time event path

- backend/app/api/websocket/manager.py and events.py implement the WebSocket channel used for low-latency transcript/status delivery.

- Data flow is backend-push rather than polling: the frontend subscribes, and the backend streams updates as the bot captures them.

- This is the key live-telemetry boundary in the architecture.

6. Bot execution subsystem

- backend/app/bot/browser.py and meet_bot.py are the autonomous meeting worker.

- It uses Playwright + headless Chromium to join Google Meet and capture captions/transcript content.

- This subsystem is isolated from the API process logic, which is important for reliability and resource control.

7. Process management and cleanup

- backend/app/core/process_pool.py suggests bot work is dispatched into separate processes rather than running inline with HTTP handlers.

- zombie_reaper.py indicates the backend actively cleans up orphaned worker/bot processes.

- This separation prevents long-running meeting joins from blocking API responsiveness.

8. Transcript and synthesis pipeline

- backend/app/bot/transcript.py likely normalizes raw caption stream into usable transcript chunks.

- backend/app/services/gemini.py is the AI synthesis layer, producing summaries, action items, and key takeaways after or during the meeting.

- The architecture is therefore: capture text → stream live → finalize into structured AI output.

9. Persistence and external services

- firebase_service.py points to Firebase/Firestore as the primary metadata and user-data backend.

- firebase_storage.py and s3_storage.py indicate artifact storage is abstracted behind service adapters, likely for transcripts/exports or media-like assets.

- External dependencies that materially affect the architecture are Firebase Auth, Firestore, Google Gemini, and Google Meet.

10. Deployment topology

- The repo is containerized with docker-compose.yml and separate Dockerfiles for backend and frontend.

- The frontend also has an Nginx config, implying production builds are served as static assets behind a web server.

- Environment-specific files (frontend/.firebaserc, firebase.json, backend env/config patterns) show the app is designed for Firebase-hosted frontend plus containerized backend services.

11. What to draw in an architecture diagram

- Show four major zones: browser UI, FastAPI API/WebSocket layer, bot worker process, and external services.

- Draw the main data path from frontend → API → bot worker → transcript stream → WebSocket → frontend, then API/bot → Gemini → Firestore/storage for persistence.

- Treat the bot worker as a distinct runtime boundary, not just a function call inside the API.