Volume 5 — 2way Platform
"2way Platform" คือกลุ่ม 5 repo ที่รองรับฟีเจอร์ "สื่อสารสองทาง" ระหว่างฝ่าย HR/แอดมิน กับพนักงาน ผ่าน LINE Official Account เป็นช่องทางหลัก — ประกาศ (announcement), แบบสำรวจ (survey), เรื่องร้องเรียน (complaint), แจ้งปัญหาการใช้งานระบบ (incident), feedback, FAQ/auto-reply, และ chat center
จากการตรวจสอบโค้ดจริงของทั้ง 5 repo พบว่ากลุ่มนี้ไม่ได้เป็น NestJS ล้วนตามที่ตารางใน docs/index.md ระบุ — เป็นระบบสองยุคซ้อนกันอยู่ (ดูหัวข้อ "ข้อค้นพบสำคัญ" ด้านล่าง)
Repository ในกลุ่ม
| Repo | Branch | Stack จริง | หน้าที่ |
|---|---|---|---|
2way-api | prod | NestJS 9 + TypeORM + MSSQL | API สำหรับ backoffice/แอดมิน (survey/announce CRUD, auth, employee proxy) — ใช้จริงบางส่วน ไม่ใช่ทั้งหมด |
2way-batch | master | NestJS 9 + TypeORM + MSSQL | Worker cron (ปัจจุบันรันแค่ stub เปล่า ไม่มี business logic ทำงานจริง) |
2way-line-service | master | NestJS 9 (module เดียว) | Gateway เรียก LINE Messaging API (push/multicast/rich menu) ให้ 2way-api เรียกผ่าน IP ตรง |
2way-meeting-backoffice | prod | Next.js 12 + React 17 + MUI | Frontend สองหน้าจอ: backoffice แอดมิน + LIFF ฝั่งพนักงาน (ชื่อ repo ทำให้เข้าใจผิดว่าเกี่ยวกับระบบประชุม แต่ไม่เกี่ยวเลย) |
2way-vtrc-api | prod | Express.js + Sequelize (MSSQL) + Mongoose (MongoDB, ปิดอยู่) | Backend หลักที่ฝั่งพนักงาน (LIFF) เรียกใช้จริง — ระบบ legacy monolith รุ่นเก่าที่ยังไม่ถูก migrate ไป NestJS |
ข้อค้นพบสำคัญ — สถาปัตยกรรมจริงของกลุ่มนี้
- มี backend สองยุคทำงานคู่กัน ไม่ใช่ NestJS เดียว —
2way-api(NestJS) จัดการเฉพาะบางฟีเจอร์ (survey/announce list ฝั่งแอดมิน, auth) ส่วน2way-vtrc-api(Express legacy) เป็น backend หลักที่ frontend ฝั่งพนักงาน (2way-meeting-backoffice, ผ่านappConnectChatAPI) เรียกใช้งานจริงมากกว่า — พิสูจน์จาก route path ที่ frontend เรียก (getProfile,verifyUserLine,getListFAQs,dropdownDivisionฯลฯ) ตรงกับ route ที่มีอยู่จริงเฉพาะใน2way-vtrc-apiดูรายละเอียดที่ 2way-meeting-backoffice/03-persistence-integrations 2way-apiเรียกกลับไปที่2way-line-serviceผ่าน IP ตรง (20.212.116.206:8200) เพื่อสลับ LINE rich menu — ไม่ผ่าน service discovery ดูที่ 2way-api/03-persistence-integrations และ 2way-line-service/index2way-batchในสถานะปัจจุบันไม่ได้ทำงานเชิงธุรกิจจริง — cron ที่ตั้งไว้รันทุก 10 วินาทีเรียกแค่ stub ที่ log ข้อความเปล่า ส่วน logic จริง (แจ้งเตือน HR admin ผ่าน LINE) ถูก comment ปิดไว้ ดูที่ 2way-batch/01-repository-map- ทั้งกลุ่มเชื่อม
cu-central-api(GraphQL, queryfetchListEmployeeForTwoWay) และcentralize-api(REST) แยกกัน —2way-apiเชื่อมทั้งสอง,2way-vtrc-apiเชื่อมเฉพาะcu-central-api(คนละ URL/port ที่ hardcode จาก2way-api) — ยืนยันความสัมพันธ์ที่ debt เดิมE-08(unconfirmed caller) ระบุไว้ว่ายังไม่ยืนยัน — ตอนนี้ยืนยันแล้วจากมุมมองของกลุ่ม 2way Platform - cross-group coupling ไปยัง
chat-center-api(Domain Microservices group) —2way-meeting-backofficeเรียกchat-center-apiตรงผ่านappConnectChatCenterAPI(websocket + REST) ดูที่ 2way-meeting-backoffice/03-persistence-integrations - repo ชื่อ "meeting" สองจุดในระบบไม่เกี่ยวกัน —
2way-meeting-backoffice(กลุ่มนี้) ไม่เกี่ยวกับ Meeting Platform group (meeting-vtrc-api/meeting-backoffice) เลย และ path/2way/MeetingAPIใน2way-vtrc-apiก็เป็นแค่โค้ดตัวอย่าง/mock ที่ยังไม่ถูกลบ ไม่ใช่การเชื่อมต่อกับระบบประชุมจริง — ควรระบุความสับสนนี้ไว้ใน canonical truths เพื่อไม่ให้ผู้อ่านเอกสารสับสนข้ามกลุ่ม - มี repo ปลายทางที่ frontend อ้างถึงแต่ไม่มีใน workspace —
2way-meeting-backofficeตั้งAPP_CONNECT_API_INCIDENTชี้ไปที่ path/incident-management-apiซึ่งไม่มี repo ชื่อนี้อยู่ใน workspace ปัจจุบัน (UNVERIFIED ว่ายังทำงานอยู่หรือถูก decommission)
Scorecard summary (รวมทั้งกลุ่ม)
| Repo | 🔴 Critical | 🟡 High | 🟢 Medium | ดูรายละเอียด |
|---|---|---|---|---|
2way-api | 4 | 2 | 6 | 04-scorecard |
2way-batch | 0 | 3 | 6 | 03-scorecard |
2way-line-service | 2 | 2 | 6 | 03-scorecard |
2way-meeting-backoffice | 0 | 2 | 6 | 04-scorecard |
2way-vtrc-api | 5 | 7 | 6 | 04-scorecard |
| รวม | 11 | 16 | 30 |
จำนวน 🔴 Critical รวม 11 รายการในกลุ่มนี้ กระจุกตัวอยู่ที่ปัญหาการยืนยันตัวตน (@Public() ทั่วระบบใน 2way-api, master bypass token และ endpoint รั่ว PII ใน 2way-vtrc-api, และ @Public() ทั้งชุดใน 2way-line-service) — ทีมดูแลควรจัดลำดับแก้ไข 2way-vtrc-api และ 2way-api ก่อน เพราะเป็นบริการที่รับ HTTP request จากผู้ใช้จริงตลอดเวลา ในขณะที่ 2way-batch มีพื้นผิวโจมตีต่ำกว่าในสถานะ cron stub ปัจจุบัน แต่ 2way-line-service ยังเปิด LINE API อำนาจเต็มแบบไม่มี auth