15.5 Legacy runtime & framework EOL

บทนี้รวบรวม debt ที่เกี่ยวข้องกับ runtime และ framework ที่เลย End of Life (EOL) — พื้นฐานของความเสี่ยงด้านความปลอดภัยในระยะยาว เพราะไม่มี patch ใหม่

สถานะ EOL ของ runtime หลัก

┌──────────────────────────────────────────────────────────────┐
│ EOL Timeline (จากข้อมูล ณ ปี 2026)                          │
├──────────────────────────────────────────────────────────────┤
│ Node.js 12     EOL 2022-04   ← vtrc-api, cu-central-api      │
│ Node.js 14     EOL 2023-04   ← vtrc-web Docker build stage   │
│ Node.js 16     EOL 2023-09   ← centralize-api                │
│ Node.js 18     EOL 2025-04                                       │
│ Node.js 20 LTS EOL 2026-04   (recommended target)             │
│ Node.js 22 LTS EOL 2027-04                                       │
└──────────────────────────────────────────────────────────────┘

ทุก service ของ VTRC รันบน Node runtime ที่เลย EOL แล้ว — ไม่มี security backport จาก Node.js project

รายการทั้งหมด

LEG-1 · Node 12 runtime

ข้อมูล	รายละเอียด
Evidence	`vtrc-api/api/Dockerfile:1` + `cu-central-api/main-api/Dockerfile:1` — `FROM node:12`
ปัญหา	Node 12 EOL เมษายน 2022 — ไม่มี security backport มาแล้วกว่า 4 ปี
Impact	CVE ใหม่ ๆ ของ Node จะไม่ถูกแก้ ความเสี่ยงด้านความปลอดภัยเพิ่มขึ้นเรื่อย ๆ
Mitigation ระยะสั้น	ยกระดับเป็น Node 20 LTS (ขั้นต่ำ) — แต่ติดปัญหา LEG-2 (esm shim)
แนวทางระยะยาว	ย้ายไป Go ที่ไม่มี runtime tax หรือ Node เวอร์ชันที่รองรับ

LEG-2 · esm shim ล็อค Node 12

ข้อมูล	รายละเอียด
Evidence	`vtrc-api/api/package.json:27` + `cu-central-api/.../package.json:26` — `"esm": "^3.2.25"`; start script `node -r esm .`
ปัญหา	`esm` เป็น shim ที่ทำให้ใช้ ES modules บน Node 12 — แต่ esm เองไม่ได้รับการพัฒนาตั้งแต่ปี 2019 และไม่รองรับ Node ≥ 14 อย่างสมบูรณ์ นี่คือ root cause ที่ทำให้ยกระดับ Node ไม่ได้
Impact	การยกระดับ Node ต้องแปลง `esm` shim เป็น native ESM (`"type": "module"`) ก่อน — เป็นงานใหญ่
Mitigation ระยะสั้น	ไม่มี — ต้องทำ migration
แนวทางระยะยาว	แปลงเป็น native ESM บน Node ≥ 14 หรือ rewrite ในภาษาอื่น

LEG-3 · Apollo Server v2 EOL

ข้อมูล	รายละเอียด
Evidence	`vtrc-api/api/package.json:18` + `cu-central-api/.../package.json:19` — `"apollo-server": "^2.x"`
ปัญหา	Apollo Server v2 ถูกแทนด้วย `@apollo/server` v4 — เวอร์ชัน v2 ไม่ได้รับ security patch
Impact	CVE ใหม่ ๆ ของ Apollo ไม่ถูกแก้ ความเสี่ยงเพิ่มขึ้นตามเวลา
Mitigation ระยะสั้น	ยกระดับเป็น Apollo Server v4 (มี breaking changes ต้องทำ migration)
แนวทางระยะยาว	ใช้ `gqlgen` (Go) หรือ GraphQL framework อื่นที่ไม่ใช่ Apollo

LEG-4 · React 16 EOL + Apollo Client v2 EOL

ข้อมูล	รายละเอียด
Evidence	frontend `package.json` ทั้งสองตัว — `react ^16`, `react-apollo ^3.1.5`, `apollo-client ^2.6.3`, `apollo-link-*`
ปัญหา	React 16 EOL, Apollo Client v2 (`react-apollo`) ถูก rename/frozen ตั้งแต่ปี 2020 และแทนด้วย `@apollo/client` v3 — ทั้ง stack frontend Apollo ไม่ได้รับการพัฒนา
Impact	ไม่ได้รับ bug fix และ security patch ความเร็วในการพัฒนา frontend ช้าลง
Mitigation ระยะสั้น	ยกระดับเป็น React 18 + `@apollo/client` v3
แนวทางระยะยาว	ย้ายไป Nuxt 3 + Vue 3

ผลกระทบรวมของ EOL stack

EOL stack ส่งผลกระทบหลายทาง:

ความเสี่ยงด้านความปลอดภัย — CVE ใหม่ไม่ถูกแก้ ผู้ไม่ประสงค์ดีที่รู้ตำแหน่งช่องโหว่เก่าสามารถใช้ exploit ได้
ความเร็วในการพัฒนา — library ใหม่ ๆ ไม่รองรับเวอร์ชันเก่า การเพิ่ม feature ใหม่ทำได้ยาก
การจ้างงาน — นักพัฒนาใหม่ไม่คุ้นเคยกับ stack เก่า การ onboard ใช้เวลานาน
การ support จาก community — Stack Overflow, GitHub issue ที่เกี่ยวกับเวอร์ชันเก่าได้คำตอบช้า

ลำดับการยกระดับ (แนะนำ)

การยกระดับ stack ต้องทำเป็นลำดับ — แต่ละขั้นต่องอาศัยขั้นก่อนหน้า:

ปัจจุบัน:  Node 12 + esm + Apollo Server v2 + React 16 + Apollo Client v2
            │
            ▼
ขั้นที่ 1:  แปลง esm shim → native ESM (จำเป็นก่อน)
            │
            ▼
ขั้นที่ 2:  ยกระดับ Node 12 → Node 20 LTS
            │
            ▼
ขั้นที่ 3:  Apollo Server v2 → v4 (backend)
            │
            ▼
ขั้นที่ 4:  React 16 → 18, Apollo Client v2 → v3 (frontend)
            │
            ▼
ขั้นที่ 5:  (อนาคต) ย้าย backend ไป Go, frontend ไป Nuxt 3

แต่ละขั้นเป็นงาน 2-3 สัปดาห์ขึ้นไป — รวมเป็น Wave 1 (stabilize) ในบท 14.10

ความเสี่ยงถ้าไม่ยกระดับ

ถ้าปล่อยให้ stack EOL ต่อไปโดยไม่ยกระดับ ความเสี่ยงเพิ่มขึ้นตามเวลา:

ระยะเวลา	ความเสี่ยงที่เพิ่ม
6 เดือน	CVE ใหม่ของ Node 12 / Apollo v2 ที่ไม่มี patch
1 ปี	library ที่ต้องพึ่ง (เช่น Sequelize, TypeORM) อาจเลิกรองรับ Node 12
2 ปี	นักพัฒนาใหม่ไม่ยอมรับงานที่ใช้ stack เก่า
3 ปี	infrastructure ใหม่ (เช่น Kubernetes version ใหม่) อาจไม่รองรับ Node 12

สรุป

ID	รายการ	Severity	Effort รวม
LEG-1	Node 12 EOL	Critical	รวมกับ LEG-2
LEG-2	esm shim ล็อค	Critical	2-3 สัปดาห์
LEG-3	Apollo Server v2 EOL	High	1-2 สัปดาห์
LEG-4	React 16 + Apollo v2 EOL	High	2-4 สัปดาห์ (ต่อ frontend)

บทถัดไปจะลงรายละเอียดของ dependency ที่ไม่ใช่ runtime แต่มีผลต่อ supply chain และ maintainability

15.5 Legacy runtime & framework EOL ​

สถานะ EOL ของ runtime หลัก ​

รายการทั้งหมด ​

LEG-1 · Node 12 runtime ​

LEG-2 · esm shim ล็อค Node 12 ​

LEG-3 · Apollo Server v2 EOL ​

LEG-4 · React 16 EOL + Apollo Client v2 EOL ​

ผลกระทบรวมของ EOL stack ​

ลำดับการยกระดับ (แนะนำ) ​

ความเสี่ยงถ้าไม่ยกระดับ ​

สรุป ​