How a trip to Egypt gets booked.

Every page is a React.lazy chunk behind a Suspense fallback. Pages that need an account are wrapped in ProtectedRoute: the dashboard, profile and inquiry tracking need a signed-in user, and the 20+ admin screens need the admin role. Old URLs like /packages redirect to their canonical page.

One QueryClient (60-second stale time, one retry). Every content query key includes the language, so English and Arabic results never mix in the cache. A shared axios instance sends cookies on every call. A server error (5xx) shows a toast. A 401 clears the cached user and returns them to sign-in.

At build time a script fetches every package. Puppeteer then renders each public route to static HTML and embeds the package data in the page. In the browser that data fills the query cache before hydrateRoot runs, so the first paint is real content and the page doesn't refetch.

English ships in the JavaScript bundle. The other ten (es, pt, tr, ar, fr, de, it, nl, ru, pl) load from the API, which fills gaps with DeepL and caches the results in SQL Server. Hand-written SEO headings for nine of the languages are locked, so machine translation can't overwrite them. Choosing Arabic sets dir="rtl" on <html> and the layout mirrors.

Endpoints send commands and queries through MediatR. FluentValidation runs as a pipeline step before any handler. Handlers depend only on interfaces. Infrastructure implements them with EF Core, MailKit, DeepL, Google sign-in, GetPayIn and Azure OpenAI (package Q&A). The domain project references no framework at all.

X-Forwarded-For is trusted only from known proxy IPs. In production the API won't start without that list, so nobody can fake their IP to dodge the rate limits. Next come CORS, JWT authentication, role checks, a CSRF guard, output caching and the rate limiter. Any exception comes back as the same JSON error shape.

Eight fixed-window rate limits run per IP, from 600 requests a minute overall down to 5 for login and the contact form. Translation routes get their own limit, because every cache miss spends DeepL credits. The request body size is capped low everywhere so ordinary routes can't be used to exhaust memory. Upload routes raise their own cap.

Login is limited to 5 requests a minute per IP. A MediatR LoginCommand is validated, the user is loaded through EF Core, and the password is checked against its BCrypt hash.

The API signs an HS256 JWT that lasts 12 hours. Issuer, audience and expiry are all checked, with zero clock skew allowed. It's sent as an httpOnly, Secure cookie, so JavaScript can't read it. The app caches only display fields (name, email) in a separate cookie. The role is never cached; it always comes from the server.

The JWT middleware reads the token from the cookie. Any cookie-authenticated request that changes data must also carry X-Requested-With, which a cross-site form can't add. On load the app asks the API for the profile; the role always comes from the server.

There is no refresh token. When the 12 hours run out, the next call returns 401: the app clears the cached user, signals the session ended, and sends the user to sign in again.

Google Identity Services gives the browser an ID token. The API checks it with Google's own library and then sets the same httpOnly cookie, so everything after sign-in works the same way.

Package, travellers, dates, rooms, hotels & cruises, supplements, review. The whole trip lives in one useReducer, so going back a step never loses anything. Day trips have their own six-step flow.

Single, double and triple rooms are priced per person. Seasonal adjustments, child and orphan discounts, private-service supplements, domestic flights and tax are applied as the traveller clicks, so the total is always visible.

Sending the inquiry is a single request. The API recalculates the total from the package data and rejects it if the numbers don't match. It then saves the booking, emails the agency through MailKit, and returns a guest token signed with an HMAC and valid for 14 days. Guests can pay without an account, and nobody can reach a booking by guessing its id.

The confirmation page offers a deposit or full payment straight away. Signed-in travellers can also follow their inquiry from the dashboard while the agency confirms it.

There are three plans: deposit (a percentage the admin sets, 20 by default), full, and balance, which only opens once the deposit is paid. The API works out the amount from the booking. If the browser sends an amount more than a cent off, the request is rejected. If an unpaid order already exists for that booking, it's reused rather than duplicated.

The API signs the request that starts the checkout with an HMAC. GetPayIn returns a checkout URL and the browser goes to GetPayIn's hosted page. Card details never reach this server. Payments can be in EGP, EUR or USD.

GetPayIn calls the API with an HMAC-SHA256 signature of the raw request body. If that header is missing, the API checks a signature field in the body instead, the same fallback GetPayIn's own plugin uses. Only after that check does the order switch to PAID. The booking's paid and due amounts then update, and its status becomes deposit_paid, or paid and confirmed.

The customer comes back to /payment-return with a signed query string. The API verifies that signature before the page shows anything, so a tampered URL gets a verification error instead of a receipt.

Each build lists the current packages, bundles with Vite and prerenders the public pages. Vercel rewrites keep /api, uploaded images and the sitemap on the main domain. The sign-in pages send a Cross-Origin-Opener-Policy header that lets the Google sign-in popup work.

A PowerShell script builds a Release publish and uploads only the changed files over FTP. During the upload an app_offline.htm takes the site offline briefly so IIS can swap the files cleanly. Secrets come from the host's environment variables. The app won't start without a JWT key or the proxy list, and it applies EF Core migrations when it boots.

robots.txt keeps crawlers out of the admin pages. The API generates sitemap.xml from the packages in SQL Server. Pages set canonical and Open Graph tags, plus JSON-LD structured data where it applies. Because the pages are prerendered, crawlers get the content without running JavaScript. The sitemap is submitted in Google Search Console.