sstent
9e0bd322d3
This commit introduces the initial version of the FitTrack Report Generator, a FastAPI application for analyzing workout files. Key features include: - Parsing of FIT, TCX, and GPX workout files. - Analysis of power, heart rate, speed, and elevation data. - Generation of summary reports and charts. - REST API for single and batch workout analysis. The project structure has been set up with a `src` directory for core logic, an `api` directory for the FastAPI application, and a `tests` directory for unit, integration, and contract tests. The development workflow is configured to use Docker and modern Python tooling.
2.6 KiB
Research Findings
Decision: Python 3.11
Rationale: Modern Python version offering performance improvements and new features.
Alternatives considered: Python 3.9, 3.10 (older, less performant).
Decision: FastAPI for API Development
Rationale: High performance, easy to use, automatic OpenAPI documentation, and strong typing with Pydantic. Well-suited for building robust APIs quickly.
Alternatives considered: Flask (less batteries-included, requires more setup for features like validation and documentation), Django (more heavyweight, better for full-stack web applications with ORM and admin panel).
Decision: Pandas, NumPy, SciPy for Data Analysis
Rationale: Industry-standard libraries for numerical operations, data manipulation, and scientific computing in Python. Essential for processing workout data efficiently.
Alternatives considered: Custom implementations (time-consuming, error-prone), R (different ecosystem).
Decision: fitparse, tcxparser, gpxpy for File Parsing
Rationale: Dedicated and well-maintained libraries for parsing common workout file formats (FIT, TCX, GPX).
Alternatives considered: Manual parsing (complex, error-prone), other less mature libraries.
Decision: Matplotlib for Chart Generation
Rationale: Powerful and flexible library for creating static, interactive, and animated visualizations in Python. Can generate various chart types required by the specification.
Alternatives considered: Plotly (more interactive, but potentially more complex for basic static charts), Seaborn (built on Matplotlib, good for statistical plots).
Decision: PostgreSQL for Data Storage
Rationale: Robust, open-source relational database with strong support for complex queries, data integrity, and scalability. Suitable for storing user configurations (FTP) and analysis results.
Alternatives considered: SQLite (simpler, file-based, less suitable for concurrent access or larger deployments), MySQL (similar to PostgreSQL, but PostgreSQL often preferred for its advanced features and open-source nature).
Decision: Pytest for Testing
Rationale: Popular, easy-to-use, and powerful testing framework for Python. Supports various testing styles (unit, integration, functional) and has a rich plugin ecosystem.
Alternatives considered: unittest (built-in, but often considered less ergonomic than pytest).
Decision: Linux Server as Target Platform
Rationale: Standard and cost-effective platform for deploying Python web applications.
Alternatives considered: Windows Server (less common for Python web apps), cloud-specific platforms (can be used on top of Linux).