Full Stack FastAPI Template

What it is

This is a full-stack web application template that combines a FastAPI backend with a React frontend. It provides a starting point for building applications with user authentication, item management, and a responsive UI based on reusable components. The template addresses the common need to quickly set up a modern web stack with features like user registration, login, item CRUD, and a professional interface without starting from scratch.

What it does

The backend exposes RESTful endpoints for user authentication (login, signup), user profile management, and item CRUD operations. The frontend provides a set of reusable React components including buttons with multiple variants and sizes, forms, dialogs, dropdowns, sidebars, tables, and password inputs. It generates a client SDK with services for items and login, using automatically generated types and schemas for type-safe API calls. Major subsystems include a user authentication hook that manages login state via localStorage and a database layer using SQLModel with user and item models. The CRUD module handles password hashing and timing‑attack‑resistant authentication. Toast notifications provide success and error feedback.

Architecture health

Twenty files are in the zone of pain and require careful modification, including the button component (in‑degree of 18), the useAuth hook (13), the loading‑button component (13), the useCustomToast hook (12), and the form component (10). There are zero import cycles, indicating a clean dependency graph. The test ratio is 10 test files for 101 source files. Two frontend files use the cva pattern for defining component variants, and one file uses react‑hook‑form for form state management. One exception class (ApiError) is defined in the frontend client. No Semgrep findings were reported.

What it enforces

The backend enforces password length constraints (8 to 128 characters) on user creation and password changes. Email uniqueness is verified when updating a user profile. Authentication requires a valid JWT token; endpoints check for valid credentials, an existing user, and an active status, raising specific HTTP errors otherwise. Password hashing uses a combination of Argon2 and Bcrypt, and the authentication function prevents timing attacks by hashing a dummy password even when the user is not found. On the frontend, form components enforce required fields and length validations via Zod schemas, and the password input component displays an error message when the error prop is provided.

Definition of Done

Backend CRUD functions commit immediately after create or update operations. On successful sign‑up, the frontend navigates to login; on error, it shows a toast. The login function stores the access token in localStorage and invalidates user queries on sign‑up settlement. The loading button disables itself when the loading prop is true and shows a spinning icon. The sidebar state persists to a cookie and toggles with Ctrl+B / Cmd+B. The custom toast hook always uses fixed titles “Success!” and “Something went wrong!” for success and error respectively.

Gaps and risks

Twenty files in the zone of pain are heavily depended upon; changes to the button component alone could affect 18 downstream consumers. The test ratio is low, with only 10 test files for 101 source files. The zone of uselessness includes four items that may not be thoroughly exercised. No concurrency risks are explicitly identified. The password reset flow relies on a token from search parameters, but no backend validation of that token’s usage is shown in the evidence. The Semgrep analysis found no issues.