FieldForge
A field-service marketplace for assigning technicians and tracking jobs from request to approval.
Used by A personal project for buyer and technician workflows, still in development.
FieldForge follows a field-service job from finding a technician to approving the finished work. It brings together work orders, bids, matching and billing in NestJS services, with a Next.js buyer portal and a React Native technician app.
This is a personal project in progress. The backend has working implementations of the main workflows, while external payments and notifications are simulated and some screens still use sample data.
- Context
- Personal project in development
- Services
- API gateway, auth, work orders, dispatch, billing and notifications
- Data
- MySQL and Drizzle; Redis location indexing and event deduplication
- Messaging
- RabbitMQ events, bounded retries and dead-letter routing
- Infrastructure
- Docker Compose, Kubernetes/Kustomize and Terraform definitions
From an open job to an on-site visit
Each work-order transition checks both the current state and who is making the request. Technician updates check the job assignment, and on-site check-in checks the submitted coordinates against a geofence on the server. A status history records the job’s progress.
Matching starts with technician locations indexed in Redis. Candidates are ranked by distance, rating, completed jobs and certification matches, with a score breakdown for each factor.
Handling retries and billing
Services share DTOs, Zod validators and event envelopes. Correlation IDs connect related activity across services. RabbitMQ consumers check for duplicate events in Redis, retry failed work a limited number of times and route exhausted retries to a dead-letter queue.
Releasing escrow takes a database transaction and a row lock. The service checks authorization and idempotency records before recording the payout and generating an invoice. The payment adapter currently simulates settlement.
Scheduled jobs check overdue work and approval deadlines. Authentication uses hashed passwords, JWT access tokens and stored hashes of refresh tokens.
What is built, and what is still in progress
The buyer portal calls work-order, bidding, dispatch and billing APIs through RTK Query. Some views fall back to sample data. The technician app includes location checks and offline synchronization, but still starts with a mock authentication token.
Docker Compose defines the local services. The project also includes Kubernetes manifests, Kustomize configuration and Terraform definitions for S3 storage. These are infrastructure definitions; cloud deployment has not been verified.
SMS and push adapters currently log their messages. Connecting real payment and notification providers, and replacing the remaining client mocks, are unfinished parts of the project.