How vishalgitgeek/dataforge works
DataForge is scaffolded as a FastAPI backend for a data-analysis platform. The visible runtime initializes configuration, request logging, API routing, and an async PostgreSQL connection; its ORM schema models users, dataset versions, processing, quality, analytics, and query history. The README is empty, and route and design-document contents were not sampled, so the domain capabilities are represented as schema responsibilities rather than an asserted working upload-to-analysis pipeline.
Main entry points: main.py FastAPI app · models.py Datasets and versions · database.py DB engine · router.py API router
Components 15
API runtime
- FastAPI app
app/main.py - API router
app/api/router.py - Health route
app/api/routes/health.py - Settings
app/core/config.py - Request logging
app/core/logging.py
PostgreSQL persistence
- DB engine
app/infrastructure/database.py - PostgreSQL
Data platform domain
- ORM models
app/models.py - Users and tokens
app/models.py - Datasets and versions
app/models.py - Processing jobs
app/models.py - Quality results
app/models.py - Analysis results
app/models.py - Query history
app/models.py
Other components
- API client
Connections 14
- API client → FastAPI app: sends requests
- FastAPI app → API router: mounts routes
- API router → Health route: includes route
- FastAPI app → Settings: loads settings
- FastAPI app → Request logging: configures logging
- FastAPI app → DB engine: disposes on shutdown
- DB engine → Settings: reads URL
- DB engine → PostgreSQL: connects
- ORM models → DB engine: uses declarative base
- Users and tokens → Datasets and versions: owns
- Datasets and versions → Processing jobs: tracks jobs
- Datasets and versions → Quality results: records checks
- Datasets and versions → Analysis results: records analyses
- Users and tokens → Query history: tracks queries