Skip to content

lukas2510/sod-sales-tracker-sample-task

Repository files navigation

Solardet Sales Tracker

A sales tracker application developed as a technical assessment. This project demonstrates modern web development practices including automated testing, type safety, and CI/CD.

Features

  • Live Counter: Animated sales counter with celebratory effects.
  • Secure: API key authentication for updates.
  • Persistence: MongoDB Atlas storage.
  • Bonus: Bulk increment support and full sales history log.

Technical Decisions

  • Architecture: Next.js 15 (Serverless) for scalability and zero-config infrastructure.
  • Quality Assurance: GitHub Actions pipeline enforcing linting, type checking, security audits, and tests on push.
  • Testing: Vitest for fast, native TypeScript unit testing of business logic.
  • Safety: Zod for runtime input validation and TypeScript for compile-time safety.
  • Real-time: Client polling (3s interval) with optimistic updates for instant feedback on own actions.
  • Logging: Console Logging for simplicity, with server logs captured by Vercel Runtime Logs and client logs in the browser.
  • Resilience: Global Error Boundaries and graceful fallbacks ensure the app never crashes unexpectedly.
  • Accessibility: Aria-live regions ensure dynamic updates are announced to screen readers.
  • Navigation: Pagination chosen over infinite scroll for predictable data access and performance.

MVP Limitations

  • Authentication: Uses simple API Key headers. Production would require OAuth or NextAuth.
  • Database: Uses MongoDB Free Tier. Production would require dedicated clusters and optimized indexing.
  • Scalability: Client polling (3s) provides near-real-time cross-client sync. See Production Real-time for alternatives.

Missing SOTA API Features

The following state-of-the-art features were omitted to maintain MVP scope and minimize dependencies:

  • Rate Limiting: No protection against abuse (e.g., Token Bucket). Implementation would introduce infrastructure complexity (Redis/Upstash).
  • Strict Query Validation: GET parameters are manually parsed. Production standards require schema-based validation (e.g., Zod) for robust type coercion.
  • Standardized Error Responses: Errors use simple JSON. SOTA APIs use RFC 7807 Problem Details for predictable error handling.
  • OpenAPI / Swagger: No automated documentation generation for external consumers.

Testing Strategy

Current coverage (MVP):

  • Unit tests for core business logic (lib/sales.ts)
  • Integration tests for API routes (app/api/sales/route.test.ts)
  • Parameterized tests for boundary conditions
  • Coverage thresholds configured (70%)

Run tests with npm test or npm run test:coverage for coverage report.

Skipped for MVP (with rationale):

Practice Rationale
CI coverage enforcement Thresholds configured locally; CI integration adds complexity for MVP
Integration tests with mongodb-memory-server Unit tests with mocks provide sufficient coverage; additional CI setup not warranted for MVP
Type-safe test fixtures / factory functions Current inline test data is sufficient for small test suite
GWT/AAA naming convention Cosmetic; current test names are descriptive enough
Snapshot / contract testing Overkill for simple API responses
Component tests (React Testing Library) Frontend is simple; manual testing sufficient for MVP
E2E tests (Playwright/Cypress) Time-intensive setup; SSE testing adds complexity
Visual regression testing Not critical for functional MVP

Edge cases not tested (with rationale):

Edge Case Rationale
Concurrent write operations Race conditions are unlikely with current usage patterns; MongoDB handles atomicity
Very large batch operations (increment/setCount > 10000) Memory/performance concerns exist but unlikely in real usage; would need load testing
API key timing attacks Constant-time comparison would be needed for production; low risk for MVP
MongoDB connection pool exhaustion Requires integration testing under load; Vercel handles connection limits
Rate limiting Not implemented; would require Redis or similar for production

Tech Stack

  • Core: Next.js 15, TypeScript
  • Styling: Tailwind CSS
  • Data: MongoDB Atlas
  • Test: Vitest

Setup & Development

This project uses Vercel's GitHub Integration for hosting.

To run locally:

  1. Clone & Install

    git clone <repo>
    cd sod-sales-tracker-sample-task && npm install
  2. Configure Environment Create .env.local:

    MONGODB_URI=mongodb+srv://<user>:<pass>@<cluster>.mongodb.net/solardet
    SALES_API_KEY=your_secret_key
  3. Run

    npm run dev

    Access at http://localhost:3000.

API Reference

GET /api/sales

Public endpoint to fetch current sales data with pagination.

Query params: page (default 1), limit (default 50, max 100)

Response: { "count": 150, "timestamps": [...], "hasMore": true, "page": 1, "limit": 50 }


POST /api/sales

Protected endpoint to increment or set sales count.

Headers: x-api-key: <key>, Content-Type: application/json

Body: { "increment": 1 } or { "setCount": 50 }


Production Real-time

The MVP uses client polling for simplicity. In production, use WebSockets + Redis Pub/Sub or a managed service like Pusher/Ably for sub-second latency.


Developed for the Solardet implementation task. (See TASK.md)

About

MVP of a sales tracker

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published