3.1 · vtrc-api

vtrc-api เป็น service แกนกลางของ legacy core — ทุก request จาก vtrc-web และ vtrc-rc-backoffice (และ backoffice อื่นในกลุ่ม Web Frontends) ผ่าน service นี้ก่อนไปถึง HR data จริงที่ cu-central-api

บทนี้เจาะ structure และ execution path ของ vtrc-api เป้าหมายคืออ่านจบแล้วรู้ว่าไฟล์ไหนอยู่ตรงไหนของ pipeline และควร track bug ต่อที่ไหน ไม่เล่า business rule ของแต่ละ domain ลึก (อยู่ Volume 1/14) ไม่ list schema ทุกตาราง (อยู่ Volume 11) และไม่ลง exploit security แบบเจาะลึก (อยู่ Volume 12/18)

ภาพรวมใน 1 รอบ

Browser ─► Nginx ─► ApolloServer (Express)
                    │
                    ├─ context()         ← gate #1: apiKey ต้องตรง API_DEVICE_KEY
                    │                    ← gate #2: ถอด JWT ดู uid (decode ไม่ verify)
                    │
                    ├─ @auth directive   ← gate #3: verifyToken
                    │                    ← gate #4: checkSession (role + jti)
                    │                    ← gate #5: checkMenuAuth (menu ABAC)
                    │
                    ├─ resolver          ← typeDefs/*.js → resolvers/*.js
                    ├─ controller        ← lib/controllers/* (orchestration)
                    ├─ repository        ← lib/repositories/* (data access)
                    ├─ Models            ← models/* (Sequelize; syncModels active = 79)
                    │                    ├─ db  → MariaDB schema {vtrc}
                    │                    └─ db2 → MariaDB schema {vtrc-centralize}
                    └─ centralize/       ← bridge ไป cu-central-api
                              ├─ GraphQL (centralize/graphql.js)
                              └─ REST auth (centralize/auth.js)
                              ▼
                          cu-central-api ─► MSSQL (HRMI) + LDAP/AD

มี 5 gates ระหว่าง request เข้ามาถึง business logic — gate ไหน fail ก็ reject ที่นั่น

ตัวเลขที่ควรจำ (verify แล้วกับโค้ดปัจจุบัน)

ตัวเลข	ค่า	ที่มา
typeDefs	44 ไฟล์	`vtrc-api/api/src/typeDefs/`
resolvers	41 ไฟล์ + `index.js` (mirror typeDefs)	`vtrc-api/api/src/resolvers/`
controllers	31 โฟลเดอร์	`vtrc-api/api/src/lib/controllers/`
repositories	31 โฟลเดอร์	`vtrc-api/api/src/lib/repositories/`
models/core	25 โฟลเดอร์ (schema `vtrc` ผ่าน `db`)	`vtrc-api/api/src/models/core/`
models/centralize	1 โฟลเดอร์ (`user` — schema `vtrc-centralize` ผ่าน `db2`)	`vtrc-api/api/src/models/centralize/`
Models sync จริงตอน boot	79 ตัว (active ใน `syncModels`, comment ออก 2 ตัว)	`vtrc-api/api/src/lib/model.js:17-95`
REST routes	1,301 บรรทัด, ~40 endpoints	`vtrc-api/api/src/routes.js`
centralize bridge controllers	17 ไฟล์, รวม 4,166 บรรทัด	`vtrc-api/api/src/centralize/controllers/`
Entry point	120 บรรทัด	`vtrc-api/api/src/index.js`

ชื่อในโค้ด ≠ ชื่อ service จริง

โฟลเดอร์ชื่อ centralize/ และ env ชื่อ END_POINT_CENTRALIZE แต่ปลายทางจริงคือ cu-central-api (Node + Apollo GraphQL) ไม่ใช่ NestJS centralize-api (REST, port 3000)

vtrc-api/api/.env.example:36-37

bash

END_POINT_CENTRALIZE="http://localhost:8082/api/graphql"
END_POINT_CENTRALIZE_AUTH="http://localhost:8082/auth"

พอร์ตต้องแยกชั้นเสมอ — ค่า 8082 ที่เห็นในนี้คือค่าตัวอย่างที่ vtrc-api ชี้ไป (CLIENT_TARGET) ไม่ใช่ default ของ cu-central-api เอง (APP_PORT=8080 — ดู Volume 3.2 cu-central-api) ไม่พบ call จาก vtrc-api ไปยัง NestJS centralize-api ในโค้ดชุดนี้ (debt E-08 — caller ไม่ยืนยัน)

รายละเอียดเต็มอยู่ใน 3.1.4 The centralize bridge

สารบัญ

บท	หัวข้อ	คำถามที่ตอบ
3.1.1	Repository map + boot sequence	process เริ่มที่ไหน โหลดอะไร
3.1.2	GraphQL request pipeline	request ผ่านกี่ gate แต่ละ gate ทำอะไร
3.1.3	Authentication & session internals	JWT, session, RBAC ทำงานอย่างไร มี bug อะไร
3.1.4	The centralize bridge	เรียก cu-central-api อย่างไร ทำไมไม่มี fallback
3.1.5	Persistence layer	Sequelize sync, transaction bug ระบบ-wide
3.1.6	Controller layer survey	31 โฟลเดอร์ controllers จัดเป็น 7 cluster
3.1.7	REST surface (routes.js)	ทำไมต้องมี REST คู่ GraphQL, qpdf ทำงานอย่างไร
3.1.8	Cron + background jobs	node-schedule ทำงานอย่างไร APP_NO คืออะไร
3.1.9	Cross-cutting concerns	logging, error format, file storage, redis ที่ตายแล้ว
3.1.10	Scorecard + known bugs	สรุปสุขภาพ repo, bug catalog, ลำดับ ROI modernize

การเปลี่ยนแปลงจาก v1

เนื้อหาพอร์ตมาจาก docs-v1-archive/volume-03-vtrc-api/ (10 บท) ทุก citation ถูกเปิดไฟล์จริงยืนยันใหม่ (2026-07-13) ผลการตรวจคือโค้ดของ vtrc-api ไม่เปลี่ยนแปลงเลยในระดับบรรทัด สำหรับไฟล์หลักที่ v1 อ้างถึง (index.js, directives/auth.js, lib/repositories/session/session.js, crons.js, routes.js, connector.js — ทุก file:line ที่สุ่มตรวจตรงกับ v1 เหมือนกันทุกประการ) ส่วนที่เปลี่ยนคือ จำนวนไฟล์ระดับโฟลเดอร์ ซึ่งสอดคล้องกับ correction ที่ canonical-truths.md บันทึกไว้แล้ว (มาจาก audit ก่อนหน้า ไม่ใช่การเปลี่ยนโค้ดใหม่ — คือ v1 นับผิดตั้งแต่แรก):

รายการ	v1 เขียนไว้	ค่าที่ verify ใหม่	เหตุผล
typeDefs	43 ไฟล์	44 ไฟล์	นับจาก `ls typeDefs/` ตรง — v1 นับขาด 1 ไฟล์
resolvers	43 ไฟล์ (mirror typeDefs)	41 ไฟล์ + `index.js` (= 42 ไฟล์ในโฟลเดอร์)	ตรงกับ canonical-truths G3
controllers	30 โฟลเดอร์	31 โฟลเดอร์	ตรงกับ canonical-truths G4
repositories	32 โฟลเดอร์	31 โฟลเดอร์	ตรงกับ canonical-truths G5
models/core	27 โฟลเดอร์	25 โฟลเดอร์	นับจาก `ls models/core/` ตรง (ไม่มี `user` — ยืนยัน canonical truth ว่า `Models.User` มาจาก `models/centralize/` เท่านั้น)

ไม่พบ claim เชิง behavior ที่ผิดจาก v1 — bug catalog, severity ranking, scorecard และ debt ID ทั้งหมดใน 3.1.10 ยังตรงกับโค้ดปัจจุบัน 100%

3.1 · vtrc-api ​

ภาพรวมใน 1 รอบ ​

ตัวเลขที่ควรจำ (verify แล้วกับโค้ดปัจจุบัน) ​

ชื่อในโค้ด ≠ ชื่อ service จริง ​

สารบัญ ​