# Go Backend Login Design

**Date:** 2026-05-07

**Goal**

Build a new standalone web app in `go_backend` that serves a server-rendered XTablo login screen using Go, `templ`, and HTMX, with no Vite pipeline and no custom application JavaScript.

**Scope**

- Replace the current SPA/Vite-oriented serving path in `go_backend`.
- Render the main login screen at `/`.
- Submit the login form with HTMX to `/login`.
- Return a server-rendered HTML fragment into the login card for feedback.
- Serve local CSS and any local static assets directly from Go.

**Out of Scope**

- Real authentication integration
- Session management
- OAuth / Google sign-in implementation
- Theme switching behavior
- Multi-page navigation beyond placeholder links

**Architecture**

The app will be a small Go HTTP service using `chi` for routing and `templ` for HTML generation. The server will expose a page route for the full login screen, a form submission route for partial updates, and a static file route for CSS and local assets.

The development server should listen on `localhost:3000`.

HTMX will be loaded from the user-specified CDN URL:

`https://cdn.jsdelivr.net/npm/htmx.org@4.0.0-beta2/dist/htmx.min.js`

No Vite integration, bundling, or custom frontend JavaScript will remain in the new app.

**Route Design**

- `GET /`
  - Returns the full login page.
- `POST /login`
  - Accepts form fields `email` and `password`.
  - Returns a small server-rendered fragment for an inline status/message region.
- `GET /static/*`
  - Serves CSS and optional local static assets.

**Server Structure**

Proposed structure:

- `go_backend/main.go`
  - Server startup and configuration.
- `go_backend/router.go`
  - Route registration.
- `go_backend/internal/web/handlers/`
  - HTTP handlers for page rendering and login submission.
- `go_backend/internal/web/views/`
  - `templ` page and fragment components.
- `go_backend/static/`
  - CSS and optional local assets.

The code should keep routing, request handling, and view rendering separated so future auth wiring does not force template logic into the router layer.

**UI Design**

The login page should visually track the provided reference:

- full-screen soft gradient background
- centered frosted/glass login card
- top row with back link and theme-toggle placeholder button
- centered XTablo brand area
- French login title and surrounding copy
- email/password fields
- forgot-password link
- primary submit button
- “Ou continuer avec” separator
- Google continuation button
- signup prompt at the bottom

The background should include decorative floating logo-like ornaments implemented with CSS positioning and animation. If the repository does not already contain usable logo assets, the page should still render cleanly with text or simple shape placeholders rather than blocking implementation on image sourcing.

**Behavior**

The app remains primarily server-rendered.

The login form will use HTMX attributes:

- `hx-post="/login"`
- `hx-target` for an inline feedback region
- `hx-swap="innerHTML"`

On submit:

- missing fields should return an error fragment
- invalid placeholder credentials should return an error fragment
- a known demo credential path may return a success fragment

This keeps the page interactive without adding custom client-side scripts.

**Validation Strategy**

For the initial implementation:

- both fields required
- simple server-side empty-value validation
- optional demo credential branch for a success state

This is sufficient for a scaffold and keeps the design aligned with the user request without inventing an auth system.

**Testing Strategy**

Use TDD at the HTTP handler level.

Minimum tests:

- `GET /` returns `200` and includes core login page content
- `POST /login` with missing fields returns an error fragment
- `POST /login` with demo credentials returns a success fragment

Additional checks:

- the Go module builds after adding `templ`
- generated templ code is committed or present in the workspace

**Risks and Mitigations**

- `templ` introduces code generation.
  - Mitigation: generate templates as part of the implementation flow and verify build output explicitly.
- Replacing the current Vite setup may leave dead code.
  - Mitigation: remove or stop referencing Vite-specific handlers and dependencies during the migration.
- Visual parity with the sample may drift without its exact assets.
  - Mitigation: match layout, hierarchy, spacing, color direction, and component treatment first; degrade gracefully on branding assets.

**Acceptance Criteria**

- Visiting `/` in `go_backend` shows a standalone login page rendered by Go.
- The server runs at `http://localhost:3000`.
- The page uses `templ` output rather than Vite or SPA mounting.
- HTMX is loaded from the specified CDN URL.
- No custom app JavaScript is added.
- Submitting the form updates an inline message region via HTMX.
- The app builds and targeted tests pass.
