Admin

Architektur, Support und Betrieb

LiveAPI Verbunden14.03.2026, 12:11
Admin & Architecture

Zielarchitektur fuer eine vermarktbare mobile Fitness-App

Diese Konsole beschreibt die neue Produktausrichtung: Mobile zuerst, mehrere Nutzer mit Login, modulare API, spaeteres Billing und ein optionales Admin-Web.

apps/mobile

primary

Primary surface for workouts, diary, body and health tracking.

apps/api

core

Central module boundary for auth, data, media, health and billing.

apps/web

optional

Optional admin, debug, support and internal product tooling surface.

Produktmodule

Explizite Modulgrenzen fuer mobile-first, mehrnutzerfaehiges Wachstum.

Produktmodule
ModulAufgabePrimaere FlaecheEntities
Authauth
Login, session lifecycle, roles and device trustsharedAuthSession
Usersusers
User account, profile and preferencesmobileUser, Profile
Workoutworkout
Exercises, plans, sessions, sets and loggingmobileExercise, WorkoutPlan, WorkoutSession, WorkoutSet
Journaljournal
Training diary, reflection and recovery notesmobileJournalEntry
Bodybody
Body measurements and composition trackingmobileBodyMeasurement
Healthhealth
Blood pressure and additional health metricsmobileBloodPressureEntry, HealthRecord
Mediamedia
Workout videos, processing and asset ownershipmobileMediaAsset
Billingbilling
Plans, subscriptions, entitlements and provider eventssharedSubscription
Adminadmin
Operations, support and internal product toolingwebn/a

Datenmodelle

BloodPressureEntry bleibt ausdruecklich eigenstaendig im Health-Modul.

Datenmodelle
DatenmodellModulKernfelder
AuthSessionauthid, userId, token, createdAt, expiresAt, lastActiveAt
Userusersid, email, passwordHash, status, role, createdAt, updatedAt, lastLoginAt
Profileusersid, userId, displayName, birthDate, sex, heightCm, primaryGoal, experienceLevel, unitsPreference, avatarAssetId
Subscriptionbillingid, userId, planCode, status, provider, providerCustomerId, providerSubscriptionId, startedAt, cancelledAt, renewalAt
Exerciseworkoutid, slug, name, category, movementPattern, equipment, isUnilateral, instructions, mediaAssetIds
WorkoutPlanworkoutid, userId, name, goal, visibility, durationWeeks, daysPerWeek, blocks, createdBy
WorkoutSessionworkoutid, userId, workoutPlanId, title, startedAt, endedAt, durationSeconds, perceivedEffort, notes, status
WorkoutSetworkoutid, workoutSessionId, exerciseId, orderIndex, setType, repetitions, weightValue, distanceMeters, durationSeconds, restSeconds, rir, notes
JournalEntryjournalid, userId, workoutSessionId, entryDate, mood, energyLevel, stressLevel, sleepQuality, notes
BodyMeasurementbodyid, userId, measuredAt, measurementType, value, unit, source, note
BloodPressureEntryhealthid, userId, measuredAt, systolic, diastolic, pulse, position, arm, note, source
MediaAssetmediaid, userId, ownerType, ownerId, kind, storageProvider, storageKey, durationSeconds, mimeType, processingStatus, createdAt
HealthRecordhealthid, userId, metricType, recordedAt, value, unit, source, provider, externalId, metadata

Roadmap

Technisch sinnvolle Reihenfolge fuer den Produktausbau.

  • 1. Architecture foundation - Freeze product modules, shared contracts and mobile-first platform boundaries.

  • 2. Auth and users - Introduce login, profiles, roles and multi-user account lifecycle.

  • 3. Workout engine - Support exercises, workout plans, sessions and per-set logging.

  • 4. Journal and body tracking - Add training diary, body measurements and explicit blood pressure tracking.

  • 5. Health integrations - Prepare Apple Health and Apple Watch ingestion through provider adapters.

  • 6. Media workflows - Link workout videos to exercises and completed sessions.

  • 7. Billing and entitlements - Introduce subscriptions, PayPal provider events and feature access control.

  • 8. Admin console - Expand the optional web surface for support, analytics and operations.

Runtime Kontext

Die bestehende Dev-Umgebung bleibt erhalten, wird aber neu fachlich ausgerichtet.

Domain
gym.weismehl.de
Umgebung
Live
API Base URL
/api
Integrationen
manual, apple_health, apple_watch, paypal