Paolo robles/fullstack 3 5

[pfooopf]

Implementation Overview

Authentication

• Technology: NextAuth.js v5 with Credentials provider
• Password Security: bcryptjs for hashing passwords
• Session Strategy: JWT-based stateless sessions
• Trade-off: Credentials provider chosen for simplicity in assessment; OAuth would be preferred for production

Database & Data Persistence

• ORM: Prisma with SQLite
• Schema: Two-table design (Users + Todos) with cascade delete for data integrity
• Database Relations: One-to-many relationship between User and Todo
• Trade-off: SQLite requires no external service setup—perfect for rapid development. PostgreSQL would be better for production scalability

API Routes (RESTful)

• GET /api/todos - Fetch user's todos (ordered by creation date, newest first)
• POST /api/todos - Create new todo
• PUT /api/todos/[id] - Update todo (toggle completion or edit title)
• DELETE /api/todos/[id] - Delete todo
• Security: All routes require authenticated session; todos filtered by userId
• Validation: Title required and non-empty; type checking for all inputs

Frontend Architecture

• Framework: Next.js 16 with App Router and React 19
• Client Components: TodoList uses "use client" with hooks for state management
• State Management: React useState/useCallback for local client state
• Trade-off: Simple React hooks used instead of external state library (like Redux) for fewer dependencies and faster development

UI/UX & Styling

• Framework: Tailwind CSS v4 for utility-first styling
• Features:
  • Dark mode support (dark:* utilities)
  • Responsive design with max-w container
  • Loading and error states with user feedback
  • Header with user email display and sign-out button
• Protected Pages: Dashboard redirects unauthenticated users to login

Key Trade-offs Made

1. Simplicity over Features: No real-time sync, no offline support—focused on core CRUD
2. Client-side State: Used React hooks instead of SWR/React Query for simpler implementation
3. Basic Validation: Input validation on client and server; could expand with more comprehensive error handling
4. JWT Sessions: Stateless sessions reduce server complexity but limit real-time logout capabilities
5. SQLite Choice: Perfect for assessment/prototyping; production would use PostgreSQL for concurrency
6. No Testing: Skipped unit/integration tests to meet 1-2 hour target; essential for production code

What Works Well

✅ Full authentication flow (signup, login, logout)
✅ Complete todo CRUD operations
✅ Data persists across sessions and browser refreshes
✅ User-specific todo isolation (no data leakage)
✅ Responsive, clean UI with dark mode support
✅ Proper error handling and loading states