Migrate from server-side rendering to Vue.js frontend

[dambrisco]

This PR represents a major architectural shift from a server-side rendered application using Pug templates to a modern Vue.js single-page application (SPA) with a REST API backend.

Summary

The application has been refactored to separate concerns between frontend and backend. The server now provides REST API endpoints instead of rendering HTML, while a new Vue.js client application handles all UI rendering and user interactions.

Key Changes

Backend (src/)

• Removed all Pug template files and server-side page rendering logic
• Converted page handlers (series.ts, registration.ts, players.ts, profile.ts, teams.ts, roster.ts, divisions.ts, seasons.ts, playoffSeries.ts, roles.ts, admins.ts, admin_groups.ts, banned_players.ts, ips.ts, index.ts) to REST API endpoints
• Created new API modules in src/api/:
  • series.ts, teams.ts, profiles.ts, registration.ts, admin.ts, players-admin.ts, seasons-admin.ts, divisions-admin.ts, me.ts, csrf.ts, rules.ts
• Removed template type definitions and pug-tree dependency
• Updated server.ts to remove template initialization and register new API routes

Frontend (client/)

• Added complete Vue.js application with:
  • Router configuration with routes for all major views
  • Pinia stores for auth and season state management
  • Vue components for all pages (HomeView, RegistrationView, ProfileView, RosterView, etc.)
  • Admin management views for seasons, divisions, players, teams, series, admins, roles, etc.
  • API client utility for communicating with backend
  • Bulma CSS styling
• Added build configuration (vite.config.ts, tsconfig.json, package.json)

Configuration

• Updated root package.json to include client build in dev/build scripts
• Updated Dockerfile to include client build step
• Removed template configuration from config.ts
• Updated tsconfig.json to exclude client directory

Implementation Details

• The API maintains the same data structures and business logic, only the presentation layer has changed
• Authentication and session management remain server-side
• CSRF protection is now provided via API endpoint
• The frontend uses modern Vue 3 composition API with TypeScript
• Pinia is used for centralized state management (auth, seasons)

https://claude.ai/code/session_019yX1hLw84s21udY91pQypp

In general, the fix is to introduce a rate‑limiting middleware for routes that perform relatively expensive operations (here, serving the SPA HTML via sendFile) and apply that middleware to those routes. For an Express app, a common approach is to use a library such as express-rate-limit to define limits (e.g., max N requests per IP per unit time) and then attach that limiter either globally or to specific routes.

For this codebase, the least invasive fix that preserves existing behavior is:

1. Import express-rate-limit at the top of src/server.ts.
2. Define a limiter specifically for the SPA catch‑all route, with reasonable defaults (for instance, 100 requests per 15 minutes per IP).
3. Apply this limiter as middleware to the app.get('*', ...) route, leaving the rest of the routing logic unchanged.

Concretely:

• At the top of src/server.ts, add an import for express-rate-limit (using the default import to match the existing ES module style imports).
• Near the SPA routing section (before line 262), create a spaRateLimiter using rateLimit({ windowMs: ..., max: ... }).
• Change app.get('*', (_req, res) => { ... }) to app.get('*', spaRateLimiter, (_req, res) => { ... }).

This localizes rate‑limiting to the highlighted filesystem‑accessing route and does not affect other API endpoints.