Infinity Gym
Manajemen gym: API .NET, CMS admin, aplikasi member mobile-first, dan landing page dua bahasa.
- Tahun
- 2026 – now
- Peran
- Co-founder dan developer, drunkcode.dev
- Jenis
- Platform · API, admin, aplikasi member
- Stack
- .NET 10 · PostgreSQL · Redis · Next.js 16 · React 19 · TanStack Query · Tailwind v4
Masalah
Sebuah gym mengelola membership, cuti membership, kelas, personal training, loker, pembayaran, dan check-in. Staf butuh satu permukaan admin untuk semuanya, dan member butuh satu aplikasi di ponsel, bukan meja resepsionis dan thread chat.
Batasan
- Satu model domain untuk member, langganan, pembayaran, kehadiran, dan training, bahkan ketika API belum membukanya.
- Sesi harus bisa dicabut: keluar atau mengganti password mengakhiri akses di semua perangkat, bukan saat token kedaluwarsa.
- Menu admin digerakkan oleh izin, jadi staf hanya melihat yang diizinkan perannya.
- Aplikasi member harus mencakup setiap alur di desain sebelum API-nya tersedia, dan dibangun oleh agen AI, sehingga setiap perubahan perlu di-review terhadap desain dan kontrak API.
Sistem
- API
- Modular monolith .NET 10 dengan modul Admin dan Members di atas satu domain bersama dan satu DbContext PostgreSQL. Controller tipis, service konkret, exception bertipe yang dipetakan oleh handler global.
- Auth
- Access dan refresh token JWT di cookie HttpOnly, dengan kebenaran sesi di Redis: sesi aktif, refresh token yang di-hash, dan daftar hitam ID token yang dicabut. Izin berupa policy string yang dicek per endpoint.
- CMS admin
- Next.js 16 dan React 19 dengan design system berbasis token sendiri. Setiap modul backend dipetakan ke satu vertical slice: page, organism, hook, wrapper TanStack Query, dan service API di sisi server.
- Aplikasi member dan landing
- Aplikasi member Next.js mobile-first yang mencakup onboarding, QR check-in, kelas, personal training, loker, dan pembayaran membership, dibangun di atas layanan mock dengan bentuk respons API. Landing page memakai Next.js dengan next-intl, bahasa Indonesia lebih dulu.
Keputusan
1.
Modular monolith, satu database
Dua modul, satu host, satu DbContext. Modul tidak saling mereferensikan; keduanya hanya bertemu di domain bersama.
Tradeoff Batas dijaga oleh referensi proyek dan review, bukan oleh jaringan.
2.
Redis memegang sesi
Token membuktikan identitas; Redis memutuskan apakah sesinya masih ada. Mencabut sesi cukup menghapus key, tanpa menunggu kedaluwarsa.
Tradeoff Setiap request terautentikasi bergantung pada Redis yang menyala.
3.
Satu slice per modul backend
CMS mencerminkan API: satu folder per modul dengan tiga file service yang sama. Endpoint baru punya tempat yang jelas.
Tradeoff Lebih banyak file per fitur, dan bentuknya harus dijaga bahkan untuk layar kecil.
4.
Mock dulu, bentuk sama
Layanan aplikasi member mengembalikan bentuk respons API dari store bersama di browser, sehingga layar dan state bisa selesai sebelum endpoint-nya ada.
Tradeoff Belum ada yang tersimpan; pekerjaan integrasi masih di depan.
5.
Dibangun agen, di-review manusia
Saya mengarahkan omp, sebuah agen AI untuk coding, membangun aplikasi member dari frame desain: saya menulis brief per modul, me-review setiap perubahan, dan menjaganya tetap sesuai bentuk respons API dan state di desain.
Tradeoff Review menjadi titik sempit, dan brief harus presisi; brief yang kabur menghasilkan layar yang meyakinkan tapi salah.
Layar
Status
Dibangun di drunkcode.dev; dalam pengembangan. Auth, menu, dan member sudah berjalan di API; langganan, pembayaran, kehadiran, dan training ada sebagai entitas dan seed data; aplikasi member berjalan dengan layanan mock. Repositori privat.
Bukti
- Repositori privat