SalesFam Platform — Technology Stack
Document Version: 1.0 Status: Draft / Active Review Parent Document: SalesFam Platform — Technical Specification
1. Purpose
Defines the technology foundation selected for developing, operating, testing, and maintaining the SalesFam platform. The stack is intended to support the platform's marketplace, sales representative, CRM, referral attribution, payment, financial, and administrative functionality while keeping the system maintainable and scalable.
2. Frontend
| Technology | Purpose |
|---|---|
| Next.js | Web application framework, routing, rendering, and public/customer-facing pages |
| TypeScript | Type-safe application development |
| Tailwind CSS | Styling and responsive UI development |
| shadcn/ui | Reusable and accessible UI components |
| React Hook Form | Form state and submission management |
| Zod | Client-side schema validation |
| axios | HTTP client for communicating with the SalesFam REST API |
| motion | UI animations and interactive motion effects |
| nprogress | Displays page and navigation loading progress |
| sonner | User-facing toast notifications and feedback messages |
| zustand | Lightweight client-side state management |
| TanStack React Query | Server-state fetching, caching, synchronization, and mutation management |
| TanStack React Table | Table functionality for sorting, filtering, pagination, and data display |
3. Backend
| Technology | Purpose |
|---|---|
| Node.js | Backend runtime |
| Express.js | REST API and HTTP request handling |
| TypeScript | Type-safe backend development |
| Prisma | Database access, schema management, and migrations |
| Zod | Server-side request and data validation |
| Argon2id or bcrypt | Secure password hashing |
| JWT | Access authentication |
| dotenv | Loads environment variables from configuration |
| EJS | Server-side HTML templating, primarily for dynamic email templates |
| ioredis | Redis client for rate limiting, caching, and asynchronous infrastructure |
| Nodemailer | Transactional email delivery |
| Winston | Application logging and structured log management |
| mysql2 | MySQL driver for database connectivity when required |
| he | HTML entity encoding and decoding for safe HTML handling |
| Helmet | HTTP security headers and common Express security protections |
4. Database & Supporting Infrastructure
| Technology | Purpose |
|---|---|
| MySQL | Primary transactional database and source of truth |
| Redis | Caching, rate limiting, and queue infrastructure |
:::danger Data Integrity Rule Redis shall not be used as the authoritative source for orders, commissions, ledger records, settlements, or payouts. :::
5. API & Documentation
| Technology | Purpose |
|---|---|
| REST | Primary application API architecture |
| Swagger UI | Interactive API documentation |
6. Email & Notifications
| Technology | Purpose |
|---|---|
| Nodemailer | Transactional email delivery |
| SMTP / Email Provider | External email delivery service |
The email provider will be selected separately based on production requirements.
7. Testing
| Technology | Purpose |
|---|---|
| Unit Testing Framework | Testing isolated business logic and services |
| Integration/API Testing Framework | Testing API behavior and component integration |
| End-to-End Testing Framework | Testing critical user flows |
Specific frameworks not yet selected.
8. Code Quality & Development Tools
| Technology | Purpose |
|---|---|
| Husky | Git hooks for enforcing checks before commits/pushes |
| ESLint | Static analysis and code quality |
| Prettier | Code formatting |
| lint-staged | Run validation checks only on staged files |
| Git | Version control |
| GitHub | Repository, collaboration, and code review |
9. Infrastructure & Deployment
Not yet defined.
10. External Service Boundary
External services should be introduced only where the platform requires functionality that should not be implemented internally. Examples include:
- Payment providers
- Email delivery providers
- Payout providers
- External commerce integrations
External services must integrate through clearly defined application boundaries so that core SalesFam business logic does not become tightly coupled to a single provider.
11. Technology Selection Principles
SalesFam should use the minimum set of technologies required to satisfy its functional and technical requirements. New technologies or infrastructure should be introduced only when they provide a clear architectural, security, performance, or operational benefit.
Technology selection should prioritize:
- Maintainability
- Security
- Reliability
- Clear separation of responsibilities
- Developer productivity
- Appropriate scalability
- Operational simplicity
The technology stack should evolve only when justified by a documented requirement or architectural need.