Backoffice Architecture

This document outlines the intended technical strategy for the backoffice application. By living within the monorepo, it maximizes reuse of existing types, domain logic, and UI components while serving as the primary tenant-facing workspace for operators.

1. Stack & Framework

• Framework: Nuxt 3 (aligning with booking-widget, passenger, etc.)
• Language: TypeScript
• Styling: Tailwind CSS + @busflow/config-tailwind

2. Component Reusability

The app will heavily rely on the existing internal packages to guarantee consistent UI/UX and dry code:

• @busflow/ui-core: For basic buttons, inputs, dialogs, standard tables.
• @busflow/types: To natively type tenant, invoice, and user objects fetched from Hasura.
• @busflow/services: For standard actions, abstracting repeated GraphQL API calls.

3. Data Access & Security

backoffice restricts data access securely via Hasura Row-Level Security (RLS) by injecting the user's x-hasura-tenant-id.

• Authentication: Must log in via an internal identity provider mechanism.
• Authorization: Employs x-hasura-role: admin or x-hasura-role: dispatcher.
• Rule: This role binds users strictly to the data owned by their assigned tenant operator. (The system reserves cross-tenant access operations for the separate admin-console application used by Busflow System Staff).

4. Integration with Backend

• For tasks extending beyond simple CRUD manipulation, the Backoffice Nuxt app will communicate with custom controllers located in apps/api/src/backoffice/ (e.g., executing the Kalkulations-Engine).