54 lines
3.5 KiB
Markdown
54 lines
3.5 KiB
Markdown
# Analysis and Next Steps
|
|
|
|
## Current State Analysis
|
|
|
|
### Architecture
|
|
- **Monorepo Structure**: The project is well-structured as a monorepo with `apps/admin` (Next.js), `apps/mobile` (Expo), and shared packages (`database`, `shared`).
|
|
- **Database Inconsistency**: There is a significant architectural inconsistency in database access.
|
|
- `packages/database` defines a Drizzle ORM schema and exports a Drizzle instance.
|
|
- `apps/admin` implements a custom `SQLiteDatabase` class (`src/lib/database/sqlite.ts`) that uses `better-sqlite3` directly with raw SQL queries and manual object mapping.
|
|
- This leads to code duplication, potential schema drift (if Drizzle schema changes but raw SQL doesn't), and loss of Drizzle's type safety and convenience features.
|
|
|
|
### Code Quality
|
|
- **Type Safety**:
|
|
- `UserManagement.tsx` defines local interfaces (e.g., `User`) that duplicate the schema definitions.
|
|
- Shared types should be utilized from `@fitai/shared` or `@fitai/database`.
|
|
- **Configuration**:
|
|
- `apps/mobile/src/config/api.ts` contains hardcoded URLs (e.g., ngrok) which is brittle for development and production.
|
|
- API routes in `apps/admin` contain `console.log` statements that should be removed or replaced with a proper logging solution.https://5e424f097c8b.ngrok-free.app
|
|
- **Error Handling**:
|
|
- Basic error handling exists in API routes, but could be standardized (e.g., custom error classes, consistent error response format).
|
|
|
|
### Testing
|
|
- **Missing Tests**: While `jest` is configured in `apps/admin`, there are no actual test files in `src`. The critical business logic in `src/lib/database` and API routes is currently untested.
|
|
|
|
## Suggested Next Steps
|
|
|
|
### 1. Unify Database Access (High Priority)
|
|
Refactor `apps/admin` to use the Drizzle ORM instance from `@fitai/database` instead of the custom `SQLiteDatabase` class.
|
|
- **Benefits**: Removes ~800 lines of raw SQL code, ensures type safety, reduces maintenance burden, and leverages Drizzle's features.
|
|
- **Action**: Replace `src/lib/database/sqlite.ts` methods with Drizzle queries using the schema from `@fitai/database`.
|
|
|
|
### 2. Implement Testing Strategy (High Priority)
|
|
Start adding tests for critical paths.
|
|
- **Unit Tests**: Add Jest tests for the database logic (if keeping the custom class temporarily) or the service layer.
|
|
- **Integration Tests**: Test API routes (`/api/attendance/*`, `/api/users`) to ensure they handle requests correctly.
|
|
- **Action**: Create `__tests__` directories in `apps/admin/src` and add initial tests for attendance flows.
|
|
|
|
### 3. Improve Configuration Management (Medium Priority)
|
|
- **Mobile**: Use environment variables (e.g., `EXPO_PUBLIC_API_URL`) for the API base URL in the mobile app instead of hardcoding.
|
|
- **Admin**: Ensure all secrets and config values are strictly in `.env` files.
|
|
|
|
### 4. Enhance Type Safety (Medium Priority)
|
|
- **Shared Types**: Move the `User` interface and other shared entities from `UserManagement.tsx` to `@fitai/shared` or use the inferred types from Drizzle schema in `@fitai/database`.
|
|
- **Action**: Refactor components to import types from the shared package.
|
|
|
|
### 5. Cleanup and Standardization (Low Priority)
|
|
- Remove `console.log` from production code.
|
|
- Standardize API error responses.
|
|
|
|
## Immediate Action Items
|
|
1. **Create a reproduction test case** for the current attendance flow to ensure no regressions during refactoring.
|
|
2. **Refactor one module** (e.g., Attendance) to use Drizzle ORM as a proof of concept for the migration.
|
|
3. **Extract types** from `UserManagement.tsx` to `@fitai/shared`.
|