singhsanket143/calendlyproject

Purpose and entry points

This is a TypeScript backend for scheduling: users define event types and availability, generate bookable slots, accept bookings, and trigger calendar/notification workflows. Process startup is split between HTTP server/bootstrap and Temporal worker runtime: src/server.ts, src/app.ts, src/temporal/worker.ts.

HTTP API composition

src/app.ts assembles Express middleware and feature routers. Route groups isolate user management, availability, event types, bookings, Google integration, and public event booking surfaces: src/routers/user.router.ts, src/routers/booking.router.ts, src/routers/public-event.router.ts. Request validation, user-ID enforcement, and centralized error/not-found handling form the API boundary: src/middlewares/validate.ts, src/middlewares/require-user-id.ts, src/middlewares/error-handler.ts.

Scheduling domain and persistence

The durable domain is modeled in Prisma and evolved through migrations, covering users, event types, availability rules/exceptions, slots, and bookings: prisma/schema.prisma, prisma/migrations/20260627172340_added_slots/migration.sql, prisma/migrations/20260627172950_added_bookings/migration.sql. Repositories are the database access boundary, separating services from Prisma/client implementation: src/repositories/db-client.ts, src/repositories/availability.repository.ts, src/repositories/booking.repository.ts.

Availability-to-slot pipeline

Availability APIs feed availability service logic, which combines rules and exceptions and delegates slot materialization/generation. Slots have distinct repository and service layers, indicating generated availability is persisted and then queried independently for booking: src/services/availability.service.ts, src/services/slot-generation.service.ts, src/services/slot.service.ts. Generation is also represented as a Temporal workflow, allowing it to run outside the request lifecycle: src/temporal/workflows/slot-generation.workflow.ts.

Booking orchestration

Booking requests enter controllers/routes, pass DTO validation, and are orchestrated through the booking service into booking and slot persistence. The likely transactional boundary is preventing a slot from remaining available once booked; implementation responsibility is concentrated in src/services/booking.service.ts, src/repositories/booking.repository.ts, and src/repositories/slot.repository.ts. Booking completion initiates asynchronous notification/calendar work rather than coupling those integrations directly to HTTP responses.

External integrations and asynchronous runtime

Temporal provides workflow execution for slot generation, booking notification, and Google Calendar operations; worker/client configuration bridges application code to the Temporal service: src/temporal/client.ts, src/temporal/workflows/booking-notification.workflow.ts, src/temporal/workflows/google-calendar.workflow.ts. Google setup and calendar service form the calendar provider boundary: src/utils/google-setup.ts, src/services/google-calender.service.ts. Email notifications use a Nodemailer configuration and booking-specific mailer: src/config/nodemailer.ts, src/mailer/booking.mailer.ts. Local infrastructure is represented by docker-compose.yml and Temporal dynamic configuration under temporal/dynamicConfig/development-sql.yaml.