1.9 KiB
Endpoints for initiating Garmin Connect authentication and linking
Decision: Authentication with Garmin Connect will utilize the direct email/password method as implemented in the existing GarminClient within GarminAnalyser.md. This leverages the garminconnect library.
Rationale: Adherence to existing project patterns and reuse of proven authentication mechanisms.
Alternatives considered: Implementing full OAuth2 flow was considered but deferred to maintain consistency with existing GarminAnalyser.md logic and simplify initial implementation.
Endpoint for initiating workout uploads to Garmin Connect
Decision: Introduce a new API endpoint, POST /api/sync/garmin/workouts, which accepts a workout identifier (e.g., workout_id from CentralDB) and triggers an asynchronous workout upload to Garmin Connect. The garminconnect library will be used for the actual interaction with Garmin's API.
Rationale: The "Technical Context" explicitly states the requirement for workout uploads and mentions "Workout" as a key entity stored in CentralDB. Implementing a dedicated API endpoint ensures clear separation of concerns and provides a standardized way for the frontend or other services to initiate this action. Asynchronous processing is crucial for long-running operations like API calls to external services, maintaining responsiveness of the main application. The garminconnect library is the logical choice for this integration given its existing use for activity downloads and its purpose as a Garmin API client.
Alternatives considered:
- Batch upload endpoint: While potentially useful, starting with a single workout upload endpoint is simpler and can be scaled to batch operations later if needed.
- Direct database trigger: Allowing direct database manipulation to trigger uploads would bypass the API layer, leading to less maintainable and less secure architecture. The API endpoint centralizes control and validation.