เหตุผลที่ Nokfa เลือก Monorepo

TL;DR

• ใช้ Monorepo เพื่อทีมเล็ก (2 คน) ดูแลง่าย แชร์โค้ดร่วม เปิดใช้งาน local dev ได้ทันที
• ลด overhead ในการตั้งค่า CI/CD หลายตัว ใช้ Vercel pipeline เดียว เพิ่มประสิทธิภาพ build ด้วย pnpm workspace + TurboRepo
• วางแผนลดความเสี่ยงด้วย mitigation และ roadmap เผื่อแตก Multi-repo ในอนาคต

---

1. บริบทของทีม Nokfa

• ทีมพัฒนาปัจจุบัน: 2 คน (Full-stack)

• เทคโนโลยีหลัก:

  • Frontend & Backend: Next.js (App Router)
  • Package manager & workspace: pnpm
  • Hosting & CI/CD: Vercel

• ความต้องการ:

  • Clone repo ครั้งเดียว → ทำงานได้ทันที
  • แบ่งงานระหว่าง /apps และ /packages ชัดเจน
  • แชร์ UI components, utilities, libs

---

2. ข้อดีหลักของ Monorepo

• แชร์โค้ดง่าย

  • วาง component, hook, util ใน /packages
  • Import ข้ามโปรเจกต์โดยตรง ไม่ต้อง publish npm
  • ลดการซ้ำซ้อนของโค้ด

• CI/CD รวมศูนย์

  • Vercel pipeline เดียวสำหรับทุกโปรเจกต์
  • ลด overhead ในการดูแลหลาย repo
  • ใช้ TurboRepo / Nx ช่วย optimize task graph

• จัดการ dependency & performance

  • pnpm workspace แชร์ node_modules ด้วย hard links
  • Build cache เร็วขึ้น เมื่อโค้ดส่วนใหญ่ไม่เปลี่ยน
  • ลดพื้นที่จัดเก็บบนเครื่อง

• Dev Experience (DX) ดีขึ้น

  • Clone ครั้งเดียว ครบทุกโปรเจกต์

  • Scripts เรียกใช้งานพร้อมใช้งานทันที

    $ pnpm install
    $ pnpm --filter web dev
    $ pnpm --filter admin-dashboard dev
    $ pnpm build
    

---

3. Risk & Mitigation

ความเสี่ยง (Risk)	ผลกระทบ (Impact)	ความเป็นไปได้ (Likelihood)	แนวทางลดความเสี่ยง (Mitigation)
Repo ขนาดใหญ่เกินไป	Clone ช้า, IDE ใช้หน่วยความจำสูง	ปานกลาง	- ใช้ sparse checkout / pnpm filter - จัด CI ให้ build เฉพาะ scope
การเปลี่ยนแปลงกระทบหลายโปรเจกต์	Build ล้มทั้งระบบ	สูง	- Configure TurboRepo caching - แยก build scopes ใน pipeline
Access Control และ Permission ซับซ้อน	Dev แต่ละคนอาจเข้าถึงไฟล์ไม่ได้ถูกต้อง	ต่ำ	- ใช้ branch protection - กำหนด CODEOWNERS ในแต่ละโฟลเดอร์
CI/CD Pipeline มีหลายขั้นตอน	ติดขัด debug ยาก	ปานกลาง	- แยก test/lint ตาม scope - ใช้ matrix jobs เพื่อ isolate
ทีมเติบโต → ความซับซ้อนเพิ่มขึ้น	อาจต้อง split repo	สูง	- วาง Roadmap เผื่อ split repo (ดู Section 5)

---

4. แนวทางลดความเสี่ยง (Mitigation)

• Sparse Checkout & pnpm filter

  • ดึงเฉพาะ package ที่ต้องการ

    $ pnpm --filter ./packages/ui dev
    

• TurboRepo / Nx Configuration

  • กำหนด pipeline ให้ build/test เฉพาะส่วนที่เปลี่ยน
  • เปิด remote cache บน CI

• Branch Strategy & Access Control

  • ใช้ Git branch model (feature, develop, main)
  • ตั้ง branch protection และ CODEOWNERS

• Monitoring & Alerting

  • เปิด GitHub Actions / Vercel Alerts เมื่อ pipeline ล้ม
  • ตั้ง Slack/Webhook แจ้งเตือน

---

5. Roadmap: เผื่อแตกไปใช้ Multi-repo ในอนาคต

1. Phase 1: สำรวจ & Planning (1–2 สัปดาห์)

   • Audit โครงสร้างปัจจุบัน
   • วาด dependency graph ระหว่าง apps กับ packages
   • ประเมิน impact ต่อ CI/CD และ DX

2. Phase 2: Extract Core Packages (2–3 สัปดาห์)

   • แยก /packages/ui → repo-shared-ui
   • แยก /packages/utils → repo-shared-utils
   • ตั้ง Git submodule หรือ private npm registry

3. Phase 3: Build & CI/CD แยก Repo (1–2 สัปดาห์)

   • สร้าง pipeline สำหรับแต่ละ repo
   • ปรับ scripts ใน apps ให้ดึง dependency จาก external repo

4. Phase 4: Validation & Migration (2–4 สัปดาห์)

   • ทดสอบ end-to-end dev & deploy
   • Debug และแก้ปัญหา dependency
   • จัด workshop ให้ dev จดจำ workflow ใหม่

5. Phase 5: สรุปผล & Optimize (ต่อเนื่อง)

   • วัด performance, DX, ความเสถียร
   • ปรับ workflow ตาม feedback

---

6. สรุป

• Monorepo ตอบโจทย์ทีมเล็ก, แชร์โค้ด, CI/CD รวมศูนย์
• มี risk เรื่อง repo ขนาดใหญ่ & CI complexity แต่ mitigable ด้วย sparse checkout, TurboRepo, branch strategy
• พร้อม roadmap split repo เมื่อทีมโตหรือความซับซ้อนเพิ่มขึ้น