Frontend Nextkt

Related documentation: Frontend Applications · Frontend Implementation · Ticketing Addon Backend (Backend-Nextkt)

Runtime status

Frontend-Nextkt is the consumer storefront for the ticketing module and now reads real data from Backend-Nextkt’s consumer API through a server-side BFF. (Venues, account Rewards/Security remain on sample data pending backend data/endpoints.)

Backend integration

• Server-side BFF only. All backend calls run in lib/server/* (a backendFetch that attaches X-Internal-API-Key + x-tenant); the internal key never reaches the browser (the backend’s CORS is unwired, so the client never calls it directly). Env: NEXT_INTERNAL_API_URL (→ :8787), NEXT_INTERNAL_API_KEY (= backend INTERNAL_API_KEY), NEXT_TENANT_ID (storefront company_id / x-tenant).
• Buyer auth is the module’s own (/consumer/auth/*, not Kisum SSO); the buyer JWT lives in an httpOnly cookie set by /api/auth/* route handlers.
• Live: home (/consumer/events), event detail (/consumer/events/{id} + /inventory + /availability; ga vs seated inferred from hotspots), My Tickets (/consumer/tickets), Profile (/consumer/me, read-only), public ticket page /t/{code}, cart add/remove (/consumer/cart*). Money is whole IDR. Checkout/payment is intentionally excluded for now.
• Pending data: Venues (the backend GET /venues Venue-module proxy is wired and the FE client exists, but Venue returns no venues yet), account Rewards + Security (no consumer endpoints).
• Local demo data: Backend-Nextkt/scripts/seed_storefront_demo.sql seeds one demo tenant (8 events, GA + seated) + a demo buyer + 2 confirmed orders.

Purpose

This app explores a ticket sales platform front page and event detail purchase experience for concerts, festivals, venues, and other live events.

It owns prototype UI only:

• event discovery
• featured event presentation
• event cards
• standing ticket tier selection
• venue-map ticket section selection

It does not own payment execution, event inventory truth, checkout sessions, or Auth/Core access.

Implemented now

• Next.js App Router application (Next 16), styled with Tailwind CSS v3.
• Design system: “Artist Tickets” — a Material-Design-3 token set keyed to the brand logo (public/images/logo.svg): teal/navy — primary #1c6e87, container + GA tier #417292, accent teal #488790, navy #1d1e4c (headings + tables tier), VIP gold #d4af37, on-sale green #10b981. Inter typography + the named spacing/typography scale. Tokens live in tailwind.config.ts + app/globals.css. (The Stitch stitch_modern_social_profile_redesign/*_new_palette explorations were mutually inconsistent on color, so the logo is the palette source of truth; layout/structure still follows the Stitch reference.)
• Brand logo rendered via components/brand-logo.tsx in the header, mobile app bar, and footers.
• Public landing page at /.
• Event detail route at /events/[slug] (statically generated per event).
• Static event data in lib/events.ts; reference imagery URLs in lib/images.ts.
• Fully responsive — each surface ships a dedicated desktop layout and a dedicated mobile layout (toggled at the md breakpoint), matching the Stitch desktop and mobile screens respectively.
• Landing sections:
  • desktop: hero carousel, category filter bar, premiere events, upcoming events grid, newsletter CTA, full footer
  • mobile: app bar, hero, filter chips, premiere carousel, signup card, upcoming list, bottom tab nav
• Event detail designs (selected by ticketMode in the data):
  • ga — general-admission flow with a sticky “Select Tickets” quantity box (desktop) and a fixed bottom buy bar (mobile)
  • seated — venue-map flow with an interactive SVG map synced to a GA/VIP/tables tier list (desktop) and a simplified map + tier cards + sticky checkout bar (mobile)
• Interactivity is client-side only (carousel, quantity steppers, section/tier selection, scroll reveal, favorite toggles). No network calls.

Current route model

Representative live pages:

• / — home
• /events/[slug] — event detail (ga general-admission vs seated venue map); e.g. /events/midnight-echoes (ga), /events/ethereal-world-tour (seated), plus the premiere/upcoming events.
• /venues — venue directory; /venues/[slug] — venue detail (SSG; e.g. /venues/the-o2-arena).
• /account — signed-in account area (shared layout + route-aware sidebar): /account (profile), /account/tickets (with QR modal), /account/rewards, /account/security.
• /support — help center (FAQ + contact form).

All UI is still frontend-only/mock-data; the account “signed-in” state, venues, and support content are static prototypes with no Auth/Core wiring.

Current integration rule

This app must remain honest about its prototype status until backend ownership is decided.

• No ticketing API contract exists from this scaffold.
• No checkout/session creation route exists from this scaffold.
• No ticket inventory source of truth exists from this scaffold.
• Static data is acceptable only for the current frontend prototype.

When ticket sales become product behavior, the future implementation must decide whether event inventory belongs in an existing Promoters/Venues flow or a new ticketing service, then update the API contract, data ownership docs, and checkout/payment docs in the same task.

Backend now exists (Backend-Nextkt)

That decision has since been made: a dedicated ticketing service was built — repo Backend-Nextkt, the Ticketing Addon Backend (Go modular monolith; owns ticketing-side inventory/holds/sales/settlement; references the Promoter event by promoter_event_id; per-ticket platform fee in its own consumer checkout). The storefront is now wired to it (see Backend integration above): the BFF calls the module’s /consumer/* routes with x-tenant, and that backend’s contract (/openapi.json) is the source of truth. Checkout/payment remains the one consumer area not yet surfaced in the UI.