Pilihan Teknologi

Mengapa Java + Spring Boot untuk Auth/Konten

Mengapa Kami Memilihnya

Java 21 dengan Spring Boot 4.0.2 adalah tulang punggung backend Yomu. Kami memilihnya karena:

• Ekosistem matang — Spring Security, Spring Data JPA/Hibernate, pattern integrasi yang luas
• Keandalan tingkat enterprise — Teruji dalam produksi pada skala besar
• Pool perekrutan besar — Pengembang Java melimpah secara global
• Tooling kuat — IntelliJ IDEA, Gradle, dan dukungan debugging yang sangat baik

Kelebihan

• Ekosistem Spring Security yang kokoh untuk autentikasi dan otorisasi
• JPA/Hibernate mengabstraksi SQL kompleks sambil mempertahankan kemampuan tuning
• Gradle Kotlin DSL menyediakan konfigurasi build yang mudah dibaca
• Dukungan IDE yang sangat baik dengan konfigurasi minimal
• Komunitas besar, dokumentasi luas, jawaban Stack Overflow untuk sebagian besar masalah

Kekurangan

• Waktu cold start lebih lambat dibandingkan bahasa JVM yang lebih baru
• Jejak memori lebih tinggi (meskipun dapat dimitigasi dengan tuning GC JVM modern)
• Sintaks verbose dibandingkan Kotlin atau Scala
• Siklus rilis Spring Boot tahunan memerlukan perencanaan upgrade

Alternatif Dipertimbangkan

Kapan Kami Akan Beralih

Kami akan mempertimbangkan beralih dari Java jika:

• Waktu startup menjadi kritis (misalnya, deployment serverless dengan cold start < 100ms)
• Kami perlu mengurangi jejak memori secara signifikan
• Pergeseran skill tim lebih condong ke Kotlin (maka kami akan bermigrasi secara bertahap)

---

Mengapa Rust + Axum untuk Gamifikasi

Mengapa Kami Memilihnya

Rust 1.85+ (Edition 2024) dengan Axum 0.8.8 menggerakkan mesin gamifikasi kami. Kami memilihnya karena:

• Abstraksi zero-cost — Performa runtime setara C++, tanpa GC pause
• Keamanan memori tanpa garbage collection — Sempurna untuk game loop yang tidak mampu menanggung lag akibat GC
• Performa async yang sangat baik — Tokio runtime menangani ribuan koneksi konkuren
• Sistem tipe kuat — Jaminan compile-time mencegah seluruh kelas bug

Kelebihan

• Performa sangat cepat (waktu response milidetik satu digit untuk query leaderboard)
• Tanpa GC pause — kritis untuk pembaruan skor real-time
• Keamanan memori tanpa overhead runtime
• Sistem tipe kuat menangkap bug pada waktu kompilasi
• Primitif konkurensi yang sangat baik (futures, async/await)

Kekurangan

• Kurva pembelajaran lebih curam, terutama bagi pengembang baru dalam systems programming
• Waktu kompilasi lebih lama (meskipun dapat dimitigasi dengan caching cargo build dan watch mode)
• Ekosistem lebih kecil daripada Java atau JavaScript
• Tidak ada runtime reflection atau dynamic dispatch (dimitigasi oleh traits dan dynamic dispatch via dyn)

Alternatif Dipertimbangkan

Kapan Kami Akan Beralih

Kami akan mempertimbangkan alternatif jika:

• Merekrut pengembang Rust menjadi sangat sulit
• Ekosistem tooling secara signifikan tertinggal dari Java/Go untuk use case kami

---

Mengapa Axum Secara Spesifik (Bukan Actix-web)

Mengapa Kami Memilih Axum

Axum 0.8.8 adalah framework web Rust pilihan kami. Kami memilihnya daripada Actix-web karena:

• Ekosistem middleware Tower — Menggunakan kembali middleware Tower yang ada (misalnya, CORS, kompresi)
• Extractor ergonomis — Parsing request type-safe dengan nol overhead runtime
• Pemeliharaan aktif tim Tokio — Didukung oleh tim di balik async Rust

Kelebihan

• Dibangun di atas abstraksi Tower yang terbukti (middleware, service, hyper)
• Extractor type-safe dan dapat dikomposisi (misalnya, Json<T>, State<AppState>, Query<T>)
• Crate kecil dan fokus — mudah dipahami dan diperluas
• Dukungan async kelas satu (non-blocking, parsing zero-copy)

Kekurangan

• Lebih baru dari Actix-web (lebih sedikit contoh pihak ketiga di lapangan)
• Komunitas lebih kecil dibandingkan Actix (tetapi berkembang pesat)

Alternatif Dipertimbangkan

Alasan Keputusan

Integrasi Tower Axum memberikan kami:

• Middleware yang dapat digunakan kembali dari ekosistem (misalnya, tower-http untuk CORS, kompresi, tracing)
• Komposisi extractor yang cocok dengan gaya Rust kami (strong typing, keamanan compile-time)
• Keselarasan dengan visi tim Tokio untuk async Rust

Kami memprioritaskan kebenaran ergonomis daripada kematangan untuk proyek greenfield ini.

---

Mengapa SQLx (Bukan Diesel/SeaORM)

Mengapa Kami Memilih SQLx

SQLx adalah ORM/query builder async Rust kami. Kami memilihnya karena:

• Pemeriksaan query compile-time — Sintaks SQL diperiksa pada waktu kompilasi dengan sqlx check
• Async-native — Dibangun dari awal untuk async/await
• Tanpa overhead ORM — Kekuatan SQL langsung tanpa kebocoran abstraksi
• Mode offline — Pra-generate query SQL untuk pengembangan offline

Kelebihan

• Validasi SQL compile-time (sqlx check berjalan sebelum kompilasi)
• Tanpa overhead ORM runtime — mapping langsung ke struct Rust
• Query type-safe dengan binding parameter
• Dukungan multi-database (PostgreSQL, MySQL, SQLite)
• sqlx migrate untuk migrasi berversi
• Mode offline (pra-generate query plan)

Kekurangan

• SQL manual diperlukan (tidak ada migrasi otomatis)
• Abstraksi lebih sedikit daripada ORM penuh (Diesel, SeaORM)
• Kurva pembelajaran untuk macro query SQLx

Alternatif Dipertimbangkan

Alasan Keputusan

SQLx mencapai keseimbangan sempurna:

• Keamanan compile-time (tidak seperti tokio-postgres mentah)
• Kontrol SQL penuh (tidak seperti abstraksi SeaORM)
• Desain async-first (tidak seperti Diesel)

Untuk modul gamifikasi kami yang kritis performa, kami membutuhkan kecepatan dan keamanan — SQLx memberikan keduanya.

---

Mengapa Next.js (Bukan Pure React/Vite)

Mengapa Kami Memilih Next.js

Next.js 16.1.6 adalah framework frontend Yomu. Kami memilihnya karena:

• pattern BFF bawaan — Rute API di domain yang sama, cookie bersama
• Dukungan SSR/SSG — Konten dinamis dan generasi statis
• Routing berbasis file — Tanpa boilerplate router
• Output standalone — Build produksi yang dioptimalkan untuk Docker
• Ekosistem masif — Shadcn/ui, React Hook Form, Zod, Tailwind CSS

Kelebihan

• Rute API menyediakan pattern Backend-for-Frontend secara native
• SSR untuk SEO dan performa render awal
• SSG untuk konten statis (dokumen bantuan, pricing)
• Routing berbasis file dengan segmen dinamis
• Incremental Static Regeneration (ISR) untuk konten near-real-time
• Next.js App Router dengan Server Components
• Mode output standalone untuk build Docker yang reproducible

Kekurangan

• Model caching yang kompleks (dapat membingungkan bagi pemula)
• Batas server/client dapat kabur (memerlukan Architecture yang disengaja)
• Lebih berat daripada Vite SPA murni (meskipun dimitigasi oleh code splitting)

Alternatif Dipertimbangkan

Alasan Keputusan

Next.js menyediakan:

• pattern BFF tanpa setup — Rute API hanyalah file di src/app/api/
• Autentikasi bersama — Cookie yang sama untuk frontend dan rute API
• RSC/Server Components — Performa lebih baik, lebih sedikit JavaScript di client
• Kesiapan produksi — Output standalone, gambar yang dioptimalkan, font

Kami memilih Next.js karena menyelesaikan masalah "lapisan perekat" kami secara native.

---

Mengapa PostgreSQL (Bukan MySQL/MongoDB)

Mengapa Kami Memilih PostgreSQL

PostgreSQL 16+ (Java) dan 17+ (Rust) adalah database utama kami. Kami memilihnya karena:

• Kepatuhan ACID — Jaminan konsistensi yang kuat
• Dukungan JSON — Tipe JSONB native untuk skema fleksibel
• Standar SQL yang kuat — Bahasa query kaya, CTE, fungsi window
• Tooling yang sangat baik — pgAdmin, psql, pg_dump, replikasi logis

Kelebihan

• Kepatuhan ACID yang kuat
• JSONB untuk storage hybrid relasional/dokumen
• Dukungan write konkuren yang sangat baik
• Fitur SQL kaya (CTE, fungsi window, full-text search)
• Teruji dalam produksi

Kekurangan

• Sedikit lebih kompleks daripada MySQL untuk setup dasar
• Lebih berat sumber daya daripada SQLite (tidak relevan untuk produksi)

Alasan Keputusan

PostgreSQL adalah pilihan database relasional default kami. Dukungan JSONB sangat berharga untuk pattern outbox dan storage metadata gamifikasi.

Kami mengevaluasi MongoDB tetapi menolaknya karena:

• Kebutuhan kepatuhan ACID
• Infrastruktur PostgreSQL yang sudah ada

---

Mengapa Redis untuk Leaderboard

Mengapa Kami Memilih Redis

Redis 8+ adalah cache dan leaderboard storage kami. Kami memilihnya karena:

• Sorted set secara native mendukung leaderboard — ZADD, ZRANK, ZREVRANK
• Latensi sub-milidetik — Performa in-memory esensial untuk game real-time
• Operasi atomik — MULTI/EXEC untuk pembaruan yang konsisten

Kelebihan

• Sorted set native — sempurna untuk use case leaderboard
• Latensi query sub-milidetik
• Operasi atomik (tanpa race condition)
• Pub/Sub untuk pembaruan skor real-time
• Opsi replikasi dan persistence

Kekurangan

• Biaya memori (data harus muat di RAM)
• Risiko kehilangan data tanpa konfigurasi persistence
• Overhead operasional (monitoring, tuning)

Alternatif Dipertimbangkan

Alasan Keputusan

Redis ADALAH standar untuk leaderboard. Sorted set-nya menyediakan:

• ZADD — Tambahkan skor secara atomik
• ZREVRANK — Dapatkan peringkat pemain dalam urutan menurun
• ZREMRANGEBYRANK — Pangkas leaderboard secara efisien

Tidak ada solusi lain yang setara dengan kombinasi kecepatan dan fitur Redis untuk use case spesifik ini.

---

Mengapa Tailwind CSS v4 (Bukan CSS Modules/styled-components)

Mengapa Kami Memilih Tailwind CSS v4

Tailwind CSS v4 adalah framework styling kami. Kami memilihnya karena:

• Pendekatan utility-first — Style lokal komponen, tanpa tabrakan penamaan
• Zero-runtime — Tanpa overhead JavaScript pada runtime
• Design token konsisten — Sistem desain terpadu
• Integrasi shadcn/ui — Diperlukan untuk pustaka komponen UI kami

Kelebihan

• Styling lokal komponen (tanpa CSS cascade global)
• Tanpa tabrakan nama class
• Pengembangan cepat dengan utility class
• Zero-runtime (style di-pre-generate)
• Spasi, warna, tipografi yang konsisten via design token
• shadcn/ui memerlukan Tailwind (integrasi mendalam)

Kekurangan

• Atribut className yang verbose
• Kurva pembelajaran untuk mindset utility-first
• Beberapa pengembang lebih menyukai ergonomi CSS-in-JS

Alasan Keputusan

Kami memilih Tailwind karena:

• shadcn/ui (pustaka UI kami) memerlukan Tailwind
• Pendekatan utility-first mencegah CSS bloat
• @layer base dan @layer components v4 meningkatkan maintainabilitas

---

Ringkasan

Setiap pilihan teknologi mencerminkan komitmen kami terhadap:

• Performa — Rust untuk gamifikasi, Redis untuk leaderboard
• Keandalan — Java untuk auth, PostgreSQL untuk data
• Kecepatan pengembang — Next.js untuk frontend, Tailwind untuk pengembangan UI cepat

Pendekatan polyglot memungkinkan kami mengoptimalkan setiap layanan untuk beban kerja spesifiknya.