pal-e-docs

Data Flow: pal-e-app

arch-dataflow-pal-e-app Architecture

architecture active
Project

Data Flow: pal-e-app

Diagram

Flow 1: Registration and First Login

Flow 2: Authenticated Board Interaction

Components

Component Purpose Notes
pal-e-landing Public entry point, registration form Static site. No auth. Redirects to Keycloak for login.
Keycloak OIDC provider — registration, login, password reset Realm: pal-e. Public client with PKCE. Self-registration TBD.
pal-e-app Authenticated SPA — renders scoped content SvelteKit, keycloak-js. Client-side API calls with Bearer token.
pal-e-docs API Content + authorization — filters by user permissions FastAPI. Extracts sub from JWT, queries UserProjectPermission.
PostgreSQL Persistent storage — notes, boards, permissions CNPG-managed. UserProjectPermission is the new table.

Key Decisions

  • Client-side auth, not SSR. pal-e-app is a SPA (ssr=false). keycloak-js handles the PKCE flow in the browser. This avoids server-side session management.
  • Permission check at API layer. The pal-e-docs API checks UserProjectPermission on every request, not the frontend. Frontend renders what the API returns — no client-side permission logic.
  • Registration may be manual initially. Lucas creates Keycloak users and assigns project permissions. Self-registration can be enabled on the Keycloak realm later if needed.
  • Token refresh is automatic. keycloak-js refreshes 30 seconds before expiry. No user-visible session interruption.