jeslor/airline_app

Purpose and entry points

Quencer Airlines is a full-stack flight-search and booking platform. The React client starts at client/src/main.tsx and composes the booking UI in client/src/App.tsx. The Express API starts at server/server.js, mounting flight, booking, and Stripe-webhook routes.

Client booking orchestration

A React Context owns cross-step flight/booking state in client/src/components/providers/FlightProvider.tsx. Search, selection, passenger details, payment, and completion are represented by client/src/components/forms/SearchFlights.tsx, client/src/components/BookingFlights/availableFlights.tsx, and client/src/components/booking/FinalizeBooking.tsx. Client API calls and Stripe browser setup are isolated in client/src/lib/api.ts and client/src/lib/stripe.ts.

Search and signed-offer boundary

The client submits validated route/date inputs, then renders server-returned offers. Server routing and request validation are split across server/routes/flights.routes.js, server/controllers/flights.controller.js, and server/schemas/flightSearch.schema.js. Google Generative AI produces dynamic flight data through server/configs/GoogleAIService.js; each offer is HMAC-signed by server/utils/offerSigning.js. Signed offer fields form the trust boundary: the client may display/select offers but cannot authoritatively set prices.

Booking and payment lifecycle

Booking submission enters through server/routes/bookings.routes.js and server/controllers/bookings.controller.js, with payload validation in server/schemas/booking.schema.js. The server verifies signed offers, computes the authoritative total, persists a pending booking through server/utils/prismaClient.js, and creates a Stripe PaymentIntent via server/utils/stripeClient.js. The client confirms that intent with Stripe Elements, then polls booking status by reference.

Webhook-driven fulfillment

Stripe—not the browser—is the payment source of truth. server/routes/webhooks.routes.js delegates payment events to server/controllers/webhooks.controller.js. Success handling must be idempotent: it confirms the stored booking, generates booking/ticket identifiers and seats through server/utils/ticketAndBookingGenerator.js, then triggers ticket delivery. This separates asynchronous payment settlement from synchronous booking initiation.

Ticket generation and delivery

Confirmed bookings are rendered into branded multi-segment PDF e-tickets using Puppeteer. Ticket HTML and branding reside in server/constants/ticketTemplate.js and server/constants/branding.js; PDF rendering is in server/utils/pdfHelper.js. server/utils/ticketDelivery.js sends the generated attachment through the Resend client in server/utils/resendClient.js. Puppeteer requires Chromium plus Render system dependencies declared in server/apt.txt.

Persistence, visualization, and deployment

MongoDB is accessed through Prisma, with the booking data model in server/prisma/schema.prisma. The client also provides a non-transactional discovery/visualization surface: interactive Three.js globe components at client/src/components/Globe/GlobeWrapper.tsx and client/src/components/Globe/Globe.tsx, backed by airport/map assets. Deployment is split: Vite/React on Vercel and Node/Express on Render; backend external dependencies are MongoDB, Google Generative AI, Stripe webhooks, Resend, and Puppeteer Chromium.