Volume 3 · Legacy Core Platform

Legacy Core คือกลุ่ม service 3 ตัวที่เป็นแกนกลางของแพลตฟอร์ม VTRC มาตั้งแต่ก่อนการแยกเป็น microservices — ทุก request จาก Web Frontends (Volume 4) และ Mobile (Volume 7) ไหลผ่านกลุ่มนี้ก่อนไปถึงข้อมูล HR จริง

Service	Stack	Role
3.1 vtrc-api	Node.js + Express + Apollo GraphQL + Sequelize + MariaDB	service แกนกลาง — รับ request จาก frontend ทั้งหมด, จัดการ welfare/leave/slip, เป็น gateway ไป cu-central-api
3.2 cu-central-api	Node.js + Apollo GraphQL + Sequelize + MSSQL + LDAP/AD	เจ้าของ authentication (LDAP/AD) และ HR data จริง (multi-tenant `SourceDB` sharding)
3.3 centralize-api	NestJS + TypeORM + MSSQL (TypeScript)	HR data facade แบบอ่านอย่างเดียว — caller ในการทำงานจริงยังไม่ยืนยัน

Topology

vtrc-web / vtrc-rc-backoffice / vtrc-backoffice(-new) / vtrc-mobile
        │  (GraphQL, apiKey + JWT)
        ▼
     vtrc-api ──(Sequelize)──► MariaDB {vtrc, vtrc-centralize}
        │
        └──(GraphQL, END_POINT_CENTRALIZE — ยืนยันแล้ว)──► cu-central-api ──► LDAP/AD + MSSQL (HRMI)
                                                                                      ▲
                                              centralize-api (REST, caller ไม่ยืนยัน) ──┘

จุดที่ต้องระวังเสมอ — โฟลเดอร์ centralize/ และ env END_POINT_CENTRALIZE ใน vtrc-api ชี้ไป cu-central-api (Node + Apollo GraphQL) ไม่ใช่ NestJS centralize-api (REST, TypeScript) แม้ชื่อจะคล้ายกันมาก — ดูรายละเอียดที่ 3.1.4 และ 3.3 index

ภาพรวมเปรียบเทียบ

มิติ	vtrc-api	cu-central-api	centralize-api
ขนาดโค้ด	~25,800 LOC (ใหญ่ที่สุด)	ระดับกลาง	~2,219 LOC (เล็กที่สุด)
API style	GraphQL (hand-written schema)	GraphQL	REST + Swagger
Database	MariaDB (Sequelize)	MSSQL HRMI (Sequelize)	MSSQL HRMI (TypeORM)
Auth	JWT + apiKey (ทำงานจริง)	LDAP/AD + JWT	JWT (ลงทะเบียนแต่ bypass 100%)
Multi-tenant `SourceDB` sharding	ไม่มี	มี	มี
Mutation endpoint	มี	มี	ไม่มี (pure read facade)
Cron jobs	มี (`node-schedule`)	มี	ไม่มี
Test coverage จริง	ไม่มี	ไม่มี	ไม่มี

ไม่มี service ใดในกลุ่มนี้มี automated test suite ที่ทำงานจริง — นี่คือความเสี่ยงร่วมกันของทั้ง Legacy Core ที่ต้องพิจารณาก่อน refactor ใดๆ

Known cross-service debt

หมวด	รายละเอียด
Auth ไม่สม่ำเสมอ	`vtrc-api`/`cu-central-api` มี auth ที่ทำงานจริง แต่ `centralize-api` bypass ทั้งหมด — ถ้า caller จริงของ `centralize-api` ยืนยันได้ ต้องแก้ auth ก่อนพิจารณาว่าปลอดภัย
Naming ที่สร้างความสับสน	`centralize/` (โฟลเดอร์ใน vtrc-api) vs `centralize-api` (repo แยก) vs `cu-central-api` (repo แยกอีกตัว) — สามชื่อคล้ายกันแต่คนละ service
Caller ที่ไม่ยืนยัน	`centralize-api` ไม่พบ caller ที่ชัดเจนในโค้ดชุดที่ตรวจสอบได้ — debt E-08
PII ใน log	ทั้ง `vtrc-api` และ `centralize-api` มีความเสี่ยง PII หลุดลง log (ผ่าน `wlog`/`GraphQLLogging` และ `logging: ['query']` ตามลำดับ)

สารบัญ

Volume	Service	บทย่อย
3.1	vtrc-api	10 บท — repository map, GraphQL pipeline, auth/session, centralize bridge, persistence, controllers, REST routes, cron, cross-cutting, scorecard
3.2	cu-central-api	4 บท — repository+bootstrap, auth/LDAP/directive, multi-tenancy/schema, integrations+scorecard
3.3	centralize-api	3 บท — repository+bootstrap/TypeORM, REST/service/entities, auth-bypass+cross-cutting+debt+scorecard

หมายเหตุการพอร์ตจาก v1

เนื้อหาทั้ง Volume พอร์ตจาก docs-v1-archive/volume-03-vtrc-api/, volume-04-cu-central-api/, volume-05-centralize-api/ ทุก citation ถูกเปิดไฟล์จริงยืนยันใหม่ (2026-07-13) รายละเอียดการเปลี่ยนแปลงเฉพาะ service อยู่ในส่วน "การเปลี่ยนแปลงจาก v1" ของแต่ละ index.md/บทสุดท้ายของ service นั้นๆ

Volume 3 · Legacy Core Platform ​

Topology ​

ภาพรวมเปรียบเทียบ ​

Known cross-service debt ​

สารบัญ ​