Skip to content
Kisum • Documentation

Frontend Nextkt

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

Runtime status

Section titled “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.)

Its sibling, Frontend-Nextkt-Admin, is the operator / promoter back-office for the same backend — see Operator admin app below. The two apps split the backend’s realms: storefront = buyer (/consumer/* + /storefront/*, x-tenant); admin = operator (/admin/*, operator JWT + x-org).

Backend integration (marketplace model)

Section titled “Backend integration (marketplace model)”
  • Server-side BFF only. All calls run in lib/server/* (backendFetch attaches X-Internal-API-Key + a per-realm tenant header); the internal key never reaches the browser (the backend’s CORS is unwired). Env: NEXT_INTERNAL_API_URL (→ :8787), NEXT_INTERNAL_API_KEY, NEXT_TENANT_ID (the default tenant for buyer auth / My Tickets / Profile only).
  • Marketplace discovery, per-event tenant. The home + event detail browse the public, tenant-less GET /storefront/events (+ /{id}) across all APPROVED orgs; the buy-side (/consumer/* inventory/availability/cart/auth/tickets) is sent with x-tenant = event.organization.id (backendFetch tenant override; cart cookie carries {session, tenant}).
  • Buyer auth is the module’s own (/consumer/auth/*, not Kisum SSO); buyer JWT in an httpOnly cookie via /api/auth/*.
  • Live: home + event detail (ga/seated from hotspots), venues list (GET /venues), real cart (/consumer/cart*, holds/totals), My Tickets, Profile, /t/{code}. Money is whole IDR.
  • Mock checkout: the cart is real; the payment step is a fake card form → demo success (no Xendit/Stripe, no /consumer/checkout).
  • Funnel analytics: a /api/track BFF (anonymous session cookie) forwards page_view / view_event / add_to_cart / checkout_started to POST /consumer/track (recorded in analytics_events).
  • White-label (per event): the event detail shows a “Presented by {org}” chip from GET /storefront/site?slug=; org logo + primary color apply when the org sets branding (blank upstream today).
  • Account: Rewards reads real loyalty (GET /consumer/points); Security shows the real current session (GET /consumer/sessions — stateless buyer JWT, no multi-device store).
  • Venue detail: /venues/{id} → Backend-Nextkt proxy → Backend-Kisum-Venues GET /internal/catalog/venues/{id} (new catalog detail).
  • Pending: full per-org white-label theming (cart/checkout/header — orgs haven’t set branding), My-Tickets-across-orgs (per-tenant today), the rewards redeem catalog + 2FA/passkeys (no backend).
  • The storefront tenant must be an APPROVED organizations row (mig 0006); scripts/seed_storefront_demo.sql provisions one for the demo tenant.

Purpose

Section titled “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

Section titled “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

Section titled “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

Section titled “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)

Section titled “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.

Operator admin app (Frontend-Nextkt-Admin)

Section titled “Operator admin app (Frontend-Nextkt-Admin)”

The operator/promoter back-office for Backend-Nextkt, separate from the consumer storefront above. Replicates the Stitch promoter-portal designs (stitch_nextkt_admin/, Material 3 / teal palette) and is wired to the backend’s operator realm. Status: v0.1 built — tsc clean, next build green (34 routes).

  • Stack. Next.js 14 (App Router) + TypeScript + Tailwind; TanStack Query for server state. Fully client-rendered SPA (no BFF) — the browser calls the backend directly with the operator JWT.
  • Auth realm (different from the storefront). Operator login (POST /operator/auth/login) → module-signed JWT, persisted client-side; every /admin/* request injects Authorization: Bearer <jwt> + x-org (the active-org selector). Header has an org switcher sourced from /operator/me. 401 clears the session → /login. (No internal key, no x-tenant — that’s the storefront.)
  • Surfaces wired to existing endpoints. Dashboard; Events (list + 3-step create wizard + detail/insights, edit, inventory/pricing, seating, advanced settings/host-mode + allocations); Orders (list + deep-dive + refund requests); Live sales (+ manual sales); Attendance (scan + guest arrivals); Discount codes; Extras (products); Comp tickets (guest list); Venues (via the /venues proxy); Settlements (per-event via /network); Analytics (funnel/daily/events); Settings (checkout + org); Branding; Team (invitations); Account (profile + change-password).
  • Honest gaps. Where a design shows a feature the backend lacks an endpoint for, the page renders a BackendGapNotice + an inert layout and logs the gap (with the endpoint it needs) in the repo’s docs/TODO.md. Notable: customer CRM / instalments, integrations directory, POS settings, custom-questions builder, live gate analytics, org-wide payout batching, report builder/export, operator session/2FA management. Buyer-facing Stitch screens (artist home, event detail, my-account, affiliates, social amplifier) are out of scope — they belong to the storefront / are unsupported.
  • Constraints worth knowing. Reservations / manual-sales / guest-list are listed per-event only (those pages use an event selector); settlements are exposed only via the per-event /network route, not org-wide; inventory has no GET-one; operator auth is a stateless JWT (no server session store → no real session-management screen).
  • Run. npm run dev on :3200; NEXT_PUBLIC_API_BASE_URL → the backend (default :8787). Repo docs: README.md, CONVENTIONS.md, docs/TODO.md, docs/CHANGELOG.md, MEMORY.md.