Habit Tracker Social
A social habit tracker whose backend reconciles manual completions and device data, protects streaks from duplicate events, and supports accountability through friends and an activity feed.
What it is
The core experience connects a personal habit to visible follow-through: plan, complete, see progress, and stay accountable with friends. Automation matters only when a device-derived completion can be trusted.
The source includes broader gamification and provider surfaces, but the documented public launch configuration is intentionally narrower: authentication, habits, dashboard, social feed, and profile/settings.
The loop it has to make believable
- 01
Create a habit, record or ingest activity, update completion and streak state, and share progress through the social feed.
- 02
Reconcile overlapping device signals before turning them into a completion, with explicit confidence handling.
How it’s built
The Spring Boot service owns durable product state in MySQL. The ingestion path combines signed webhooks, scheduled synchronization, retry behavior, and deduplication before reconciliation logic updates habit progress.
Source-specific fusion and confidence thresholds handle conflicting observations. React and React Native clients sit above that state, with realtime updates and deployment checks kept separate from provider capability claims.
Architecture
- Product state
- Spring Boot and MySQL own habits, completions, streaks, friendship, and feed behavior
- Ingestion
- Provider capability checks, signed webhooks, replay protection, scheduled retries, and stable deduplication keys
- Reconciliation
- Source-aware fusion strategies and confidence gates decide how incoming data contributes to completion
- Clients
- React and React Native interfaces, with STOMP/WebSocket events for live updates
- Release
- Feature flags, dependency-aware health checks, production preflight, and authenticated smoke scripts
What has to hold up
- Deduplicate webhook and scheduled-sync data so retries do not inflate activity or create duplicate credit.
- Keep unsupported providers and optional features outside the public launch configuration until their integration paths are verified.
Launch and provider boundaries
The README identifies Fitbit and direct device ingestion as implemented paths; other provider names include scaffolds. That is a source-level capability statement, not evidence that every integration has been exercised with production credentials.
No verified public web or API URL is recorded. Deployment still depends on account configuration, infrastructure, credentials, and a passing deployed smoke. Optional features remain gated in the documented launch configuration.
Proof
VerifyRepository, checks, stack, status
- 01
Use the README's local Compose demo and follow the habit-to-feed loop.
- 02
Inspect ingestion, fusion, completion, and authentication tests in the backend source.
- 03
Read the provider capability matrix and compare it with the frontend launch flags.
- 04
Follow DEPLOYMENT.md for preflight and smoke checks before describing any hosted environment as live.
- Role
- Product state, backend integration, ingestion correctness, social features, and deployment preparation
- Scope
- Habit and social backend, web interface, mobile client, and provider ingestion
- Proof
- README provider matrix; DEPLOYMENT.md; backend controller/service tests; scripts/production-preflight.sh; deployment smoke tooling
- Stack
- Java, Spring Boot, MySQL, Redis, React, React Native, TypeScript, WebSocket/STOMP
- Core loop
- Plan → complete → share
- Signals
- Manual + device ingestion
- Data path
- Deduplication and fusion
- Launch
- Core features gated