Next steps

FitTrack ไปต่อทางไหนจากนี้

คุณมี slice ของ product ที่ deploy แล้วและซื่อตรง: client สองตัว, FastAPI backend เดียว, managed Supabase, tests, และ container บน cloud recap → บอกชื่อสิ่งที่ตั้งใจตัดออกไปแล้ว หน้านี้เปลี่ยนการละเว้นเหล่านั้น — บวกกับข้อกังวลเรื่อง production อีกไม่กี่อย่าง — ให้เป็น roadmap แต่ละส่วนขยายบอก สิ่งที่ได้เรียนรู้ และ จุดที่เสียบเข้า ไม่มีอันไหนเป็นการเขียนใหม่ ทุกอันห้อยอยู่บน seam ที่คุณสร้างไว้แล้ว

เลือกตามสิ่งที่คุณอยากเรียนต่อ ไม่ใช่ตามลำดับ

Training programs & plans

Teaches: การ model ข้อมูลแบบ prescriptive (plan คือ template ของงานในอนาคต) และการ generate scheduled session จาก template นั้น — รูปร่างที่ต่างจริง ๆ จากตาราง “log สิ่งที่เกิดขึ้น” ที่คุณมี
Plugs in: ตาราง programs / plan_days ใหม่ผ่าน Supabase migration, router programs ข้าง ๆ workouts, และ action “เริ่ม session วันนี้จาก plan ของฉัน” ใน Flutter tracking UI

Teaches: ความสัมพันธ์ many-to-many (follows), visibility rules, และ feeds — ครั้งแรกที่ RLS policies ของคุณให้สิทธิ์อ่าน ข้าม user แทนที่จะกั้นแต่ละคนให้อยู่แต่ row ของตัวเอง
Plugs in: ตาราง follows และ endpoint GET /feed บน backend; flag is_public ที่มีอยู่แล้วบน exercises คือ pattern ที่ต่อยอดไปยัง workouts ได้

Nutrition tracking

Teaches: การ integrate third-party food/barcode API และการ aggregate metric stream ที่สอง (แคลอรี, มาโคร) เคียงข้างกับ training volume
Plugs in: router nutrition และตารางใหม่ทั้งชุด โดยใช้ auth dependency และ repository pattern เดียวกัน — เป็น test ที่สะอาดว่า domain layer ของคุณ reuse ได้จริงหรือไม่

Offline sync in Flutter

Teaches: ข้อมูล mobile แบบ local-first — device cache (Drift/SQLite), outbox queue, และ conflict resolution เมื่อโทรศัพท์ reconnect ยากที่สุดในหน้านี้ และมีค่ามากที่สุด
Plugs in: ห่อ Flutter API client เพื่อให้การเขียนไปลง local store ก่อนแล้ว sync ทีหลัง; endpoint ของ backend ไม่เปลี่ยน ซึ่งนั่นคือประเด็น

Push notifications

Teaches: การ register device token, server-side trigger, และการ deliver ผ่าน APNs/FCM — งานแบบ event-driven ที่เอื้อม ออกไป หา user แทนที่จะตอบ request
Plugs in: ตาราง device_tokens, background task ใน FastAPI (“rest timer ของคุณหมดแล้ว”, “เพื่อนแชร์ workout”), และ user id ของ Supabase Auth เป็น join key

Real observability

Teaches: การมองเห็น production — structured logging, distributed traces ด้วย OpenTelemetry, และ error reporting ด้วย Sentry — เพื่อให้คุณ diagnose API ที่ deploy แล้วแทนที่จะเดา
Plugs in: OTel middleware บน FastAPI app และ Sentry SDK ใน client ทั้งสอง; /health check จาก Module 1 กลายเป็นสัญญาณหนึ่งในหลาย ๆ ตัว

CI/CD for the monorepo

Teaches: การ automate repo ที่มี build system สองแบบ — รัน pytest และ Flutter tests ทุกครั้งที่ push แล้ว build และ deploy container เมื่อเขียว
Plugs in: GitHub Actions workflow ที่มี path filter เพื่อให้การเปลี่ยนใต้ api/ ไม่ทำให้ต้อง rebuild Flutter app ต่อสายตรงเข้ากับ Fly.io deploy ที่คุณทำด้วยมือ

Rate limiting & caching

Teaches: การปกป้องและเร่ง backend — per-user rate limit และการ cache read ที่ร้อน (progress aggregations คือตัวเลือกชัดเจน เพราะคำนวณตัวเลขเดิมซ้ำ ๆ)
Plugs in: middleware บวก Redis instance ที่ API คุยด้วย; id จาก get_current_user กลายเป็น rate-limit key ตามธรรมชาติ

ปิดท้ายคอร์ส

นั่นคือ FitTrack คุณเริ่มจาก directory ว่างเปล่ากับ uv และจบด้วย native app ที่ deploy แล้ว, web companion, FastAPI backend ที่มี test, และ managed Supabase อยู่เบื้องหลัง — บวกกับชุดการตัดสินใจเชิงสถาปัตยกรรมที่คุณ defend และ map ได้ชัด ของทุกอย่างที่ระบบทำและทุกอย่างที่ตั้งใจไม่ทำ

ถ้าคุณอยากกลับไปดูรูปร่างของทั้งหมดอีกครั้ง architecture overview → อ่านแล้วรู้สึกต่างออกไปตอนนี้ที่คุณสร้างทุกกล่องใน diagram นั้นมาแล้ว

Source เต็มอยู่ที่ github.com/avetavos/realworld-fittrack — clone, fork, แล้วพาไปที่ไหนก็ได้ที่คุณชอบ ไม่ว่าคุณจะสร้างอะไรต่อ ตอนนี้คุณรู้แล้วว่าชิ้นส่วนต่าง ๆ ประกอบกันอย่างไร ไป log some sets กัน