aakash-kr-7/google_calender_clone

1. Overall shape

- This is a split full-stack calendar app: a React single-page frontend in frontend/ and a FastAPI backend in backend/, with a local SQLite database as the persistence layer.

- The main user flow is: browser UI → API requests → backend validation/business logic → SQLite → response back to the UI.

2. Frontend boundary

- The frontend is a Vite/React app organized around calendar views and event interactions rather than a generic page hierarchy.

- src/App.jsx and src/main.jsx boot the app, while components/layout/ provides the shell, navigation, palette, sidebar, and settings surfaces that frame the calendar experience.

3. Calendar rendering subsystem

- The calendar UI is split into components/views/DayView.jsx, WeekView.jsx, and MonthView.jsx, backed by lower-level calendar primitives in components/calendar/.

- TimeGrid, AllDayRow, and MiniCalendar suggest the page is composed from reusable layout blocks that are reused across views rather than fully separate screens.

4. Event interaction subsystem

- Event creation and editing are centered in components/events/ through modal, popover, hover-preview, form, and block components.

- This indicates the UI supports multiple event entry points: clicking a time slot, editing an existing event, hovering for details, and dragging/resizing blocks directly on the calendar.

5. Client-side state and data access

- The app uses small client-side stores in src/store/ (calendarStore.js, eventStore.js, settingsStore.js) plus hooks like useEvents, useDragDrop, and useResize.

- src/api/client.js is the network boundary: the UI state reads from and writes to the backend through this client, rather than talking to the API directly from components.

6. Frontend business logic

- Calendar-specific calculations are kept in src/utils/, including date handling, event layout, slot finding, and timezone conversion.

- This separation matters because the frontend is not just rendering server data; it also computes event positioning, conflict-adjacent UX, and local-time display behavior before painting the calendar.

7. Authentication boundary

- The backend exposes an auth router in backend/app/routers/auth.py, and the frontend has dedicated LoginPage.jsx and RegisterPage.jsx.

- The README indicates JWT-based auth and Google OAuth support, so authentication is a first-class boundary between anonymous entry, signed-in state, and protected event operations.

8. Backend API structure

- FastAPI route handlers are divided into routers/auth.py and routers/events.py, which keeps identity concerns separate from calendar CRUD and scheduling concerns.

- backend/app/main.py is the application entrypoint, while backend/app/__init__.py and backend/app/database.py anchor startup and persistence setup.

9. Backend domain model and service layer

- Domain objects live in backend/app/models/ with at least user.py and event.py, and request/response contracts are defined separately in backend/app/schemas/.

- Event-specific business logic is pushed into backend/app/services/event_service.py, which is the main place where the app likely handles overlap detection, recurrence-aware behavior, and mutation rules before data hits the database.

10. Persistence and migration path

- SQLite is the storage backend, with database initialization/migration handled by backend/migrate.py.

- The README and file layout suggest a simple single-file database deployment model, which fits the repo’s local/dev-friendly setup and the Render deployment described in the docs.

11. Time handling boundary

- backend/app/utils/timezone.py and frontend/src/utils/timezone.js show that timezone conversion exists on both sides of the stack.

- This is important architecturally because calendar correctness depends on keeping stored timestamps, API payloads, and rendered local times aligned across the client/server boundary.

12. Deployment split

- The repo is designed for separate deployment of frontend and backend: the frontend on Vercel and the backend as a Python service on Render.

- That means the browser talks to the API over the network, and the frontend is not server-rendered by the backend.

13. Notable cross-cutting concerns

- The codebase clearly treats event scheduling as a core domain concern: dragging, resizing, popovers, command palette actions, and modal editing all converge on the same event data model.

- The architecture therefore revolves around one central resource type, event, with user acting as the access boundary and ownership boundary.

14. Good diagram anchors

- For an architecture diagram, the most important boxes are: React UI shell, calendar view layer, event interaction layer, client state/API client, FastAPI routers, event service, auth service, and SQLite tables for users/events.

- The key arrows are: user actions into React, React into API client, API client into auth/events routers, routers into service logic, service into SQLite, and responses back to the stores/UI.