Two HTTP patterns
The client uses two different HTTP approaches — both coexist in the codebase:1. Axios (configured in main.js)
2. XMLHttpRequest (Promise-wrapped)
The dominant pattern across the codebase:There’s no centralized API service layer. Each component defines its own API calls inline in its
methods block. The apiFunctions.js file has a few shared helpers but most calls are component-local.Authentication
For the backend implementation of the auth system (custom Redis token guard), see Authentication architecture.How it works
- User logs in via
POST /auth/login(or registers viaPOST /auth/register) - Backend returns a
session_keytoken - Client stores it in component state (passed via props) or
sessionStorage - Subsequent requests include
sessionKeyheader
Storage
- Component state —
session_keypassed through props between components - sessionStorage — used in Dashboard (
sessionStorage.setItem('session_key', ...)) - No localStorage — session doesn’t persist across browser close
- No refresh token mechanism — if the token expires, user must re-login
API helper functions
File:src/assets/scripts/apiFunctions.js
Complete API endpoint map
Every API endpoint the client calls, mapped to the backend. For full backend endpoint documentation, see the API Reference.Authentication (backend docs)
Users & profiles (backend docs)
Booking & lessons (backend docs)
Payments (backend docs)
Other
Data structures
No TypeScript — these are the implicit shapes used across the codebase:User object
Registration payload
Booking payload
Error handling
No global error interceptor. Each component handles errors locally:- Login: 404 = user not found, 401 = invalid credentials
- Payment: insufficient funds, 3D Secure failures with specific messages
- Registration: duplicate email/username with API error text display