1 
2เมื่อทำงานกับโปรเจกต์ซอฟต์แวร์ที่ซับซ้อน การเลือกระหว่าง monorepo และ polyrepo สามารถส่งผลกระทบอย่างมากต่อประสิทธิภาพของทีมและความสามารถในการขยายโค้ด ในบทความนี้ เราวิเคราะห์ความแตกต่าง ข้อดีและข้อเสียของแต่ละแนวทาง และช่วยคุณเข้าใจว่าแบบไหนเหมาะกับคุณ
3 
4## Monorepo และ Polyrepo คืออะไร?
5 
6### Monorepo
7 
8**Monorepo** (monolithic repository) คือ repository เดียวที่เก็บซอร์สโค้ดสำหรับหลายโปรเจกต์ บริการ หรือแพ็กเกจ ซึ่งมักเกี่ยวข้องกัน
9 
10```plaintext filename="Example Monorepo Structure"
11my-monorepo/
12  packages/
13    frontend/
14    backend/
15    shared/
16  package.json
17  turbo.json
18```
19 
20### Polyrepo
21 
22**Polyrepo** (multiple repositories) หมายความว่าแต่ละโปรเจกต์ บริการ หรือแพ็กเกจมี repository แยกของตัวเอง
23 
24```plaintext filename="Example Polyrepo Structure"
25repos/
26  frontend/
27    package.json
28  backend/
29    package.json
30  shared/
31    package.json
32```
33 
34## ความแตกต่างเชิงภาพ
35 
36```mermaid
37flowchart TD
38    subgraph Monorepo
39        A1["frontend/"]
40        A2["backend/"]
41        A3["shared/"]
42    end
43    style Monorepo fill:#e0e7ff,stroke:#6366f1,stroke-width:2px
44```
45 
46```mermaid
47flowchart TD
48    subgraph Polyrepo
49        B1["frontend repo"]
50        B2["backend repo"]
51        B3["shared repo"]
52    end
53    style Polyrepo fill:#fee2e2,stroke:#ef4444,stroke-width:2px
54```
55 
56## ข้อดีและข้อเสีย
57 
58### Monorepo
59 
60**ข้อดี:**
61- ทำให้การแชร์โค้ดง่ายขึ้น (เช่น ไลบรารีที่ใช้ร่วมกัน)
62- การ refactoring แบบ atomic ข้ามหลายโปรเจกต์
63- การจัดการ dependency และการตั้งค่าแบบรวมศูนย์
64 
65**ข้อเสีย:**
66- อาจหนักขึ้นเมื่อ codebase เติบโต
67- ต้องการเครื่องมือในการจัดการ build/test บางส่วน (เช่น Nx, Turborepo)
68 
69### Polyrepo
70 
71**ข้อดี:**
72- แต่ละทีม/โปรเจกต์เป็นอิสระ
73- จัดการง่ายกว่าสำหรับโปรเจกต์เล็ก
74- อนุญาตนโยบายการเข้าถึงแบบละเอียด
75 
76**ข้อเสีย:**
77- แชร์โค้ดยากขึ้นโดยไม่ต้องเผยแพร่แพ็กเกจ
78- การ refactoring ข้าม repo ซับซ้อนกว่า
79- อาจมีการตั้งค่าซ้ำกัน
80 
81## ตัวอย่างจริง: Monorepo กับ Turborepo
82 
83สมมติว่าคุณต้องการสร้าง monorepo ที่มี frontend และ backend โดยใช้ Turborepo
84 
85### 1. เริ่มต้น monorepo
86 
87```bash
88npx create-turbo@latest
89```
90 
91### 2. โครงสร้างทั่วไป
92 
93```plaintext
94my-monorepo/
95  apps/
96    web/        # frontend Next.js
97    api/        # backend Node.js/Express
98  packages/
99    ui/         # shared component library
100    utils/      # shared functions
101  turbo.json
102  package.json
103```
104 
105### 3. ตัวอย่าง workspace ใน `package.json`
106 
107```json
108{
109  "private": true,
110  "workspaces": [
111    "apps/*",
112    "packages/*"
113  ]
114}
115```
116 
117### 4. ตัวอย่างการ import ไลบรารีที่ใช้ร่วมกัน
118 
119สมมติว่าคุณมีฟังก์ชันใน `packages/utils/src/formatDate.ts`:
120 
121```ts
122// packages/utils/src/formatDate.ts
123export function formatDate(date: Date): string {
124  return date.toLocaleDateString('en-US');
125}
126```
127 
128ใน frontend:
129 
130```ts
131// apps/web/pages/index.tsx
132import { formatDate } from '@myorg/utils';
133 
134export default function Home() {
135  return <div>Today is {formatDate(new Date())}</div>;
136}
137```
138 
139## เมื่อไหร่ควรเลือก Monorepo?
140 
141- ทีมขนาดกลาง-ใหญ่ที่ทำงานหลายโปรเจกต์ที่เกี่ยวข้องกัน
142- ต้องการแชร์โค้ดและทำ refactoring ขนาดใหญ่
143- โปรเจกต์ที่เติบโตเร็วและต้องการ build/test ที่เหมาะสม
144 
145## เมื่อไหร่ควรเลือก Polyrepo?
146 
147- โปรเจกต์เล็กหรือเป็นอิสระ
148- ทีมแยกกันทำงานบนผลิตภัณฑ์ที่แตกต่างกัน
149- นโยบายการเข้าถึงที่เข้มงวดมาก
150 
151## สรุป
152 
153ไม่มีโซลูชันที่สมบูรณ์แบบสำหรับทุกคน การเลือกขึ้นอยู่กับขนาดทีม ความซับซ้อนของโปรเจกต์ และความต้องการในการทำงานร่วมกัน สิ่งสำคัญคือตระหนักถึงข้อแลกเปลี่ยนและเลือกเครื่องมือที่เหมาะสมในการจัดการความซับซ้อน
154