6.9 · Scorecard + เปรียบเทียบ service อื่น
บทสุดท้ายของเล่มสรุป scorecard ของ benefit-api เปรียบเทียบกับ service อื่นในระบบ VTRC และให้ข้อแนะนำเชิงกลยุทธ์
Scorecard ภาพรวม
| Category | Score (1-5) | หมายเหตุ |
|---|---|---|
| Documentation | 1 | ไม่มี README ที่ใช้งานได้, comments กระจัดกระจาย, Swagger auto-gen แต่ไม่ครบ |
| Test coverage | 1 | ไม่มี unit/integration test ที่ใช้งานได้ (CI lint/test commented out) |
| Type safety | 2 | TypeScript แต่ใช้ any เยอะ (body: any, payload: any) |
| Error handling | 2 | try/catch มีบ้าง แต่ mostly swallow + return generic error |
| Logging | 3 | NestJS Logger ใช้งานได้, แต่บางที comment ออก (jwt.strategy.ts:18) |
| Security | 1 | Critical debt 6 รายการ (ดู 6.8) |
| Code organization | 3 | NestJS module structure ใช้ได้, แต่ service file บางไฟล์ใหญ่มาก (7,740 lines) |
| Dependency hygiene | 2 | vtrc-common file: reference, Node version skew, dependencies หลายตัวเก่า |
| Observability | 2 | ไม่มี metrics, ไม่มี tracing, ไม่มี healthcheck ที่ใช้งานได้ |
| Deploy safety | 2 | ไม่มี blue/green, ไม่มี rollback script, .env baked |
คะแนนเฉลี่ย: 1.9 / 5
เปรียบเทียบกับ service อื่น
| Aspect | benefit-api (Vol 6) | centralize-api (Vol 5) | vtrc-api (Vol 3) | cu-central-api (Vol 4) |
|---|---|---|---|---|
| Stack | NestJS 9 + TypeORM + MSSQL | NestJS 9 + TypeORM + MSSQL | Node.js + Apollo GraphQL + Sequelize | Node.js 12 + Apollo + Sequelize + LDAP |
| Auth | JWT (broken) | JWT (ปิดหมดด้วย @Public()) | JWT + @auth directive (RBAC) | LDAP + @auth directive |
| DB access | sa x3 connections | Least-priv user | Sequelize ORM | Sequelize + SourceDB sharding |
| ORM pattern | Raw SQL + Repository mix | Repository + QueryBuilder | Sequelize models | Sequelize models |
| SQL safety | Template literal injection | Parameterized ทั้งหมด | Sequelize ORM (mostly safe) | Sequelize ORM + raw parameterized |
| Cross-schema writes | เขียนตรงไป vtrc | อ่านจากหลาย schema | เขียนเฉพาะ vtrc | อ่านเฉพาะ |
| Cron/scheduler | มี (HRMI pull/push) | ไม่มี | ไม่มี (frontend-triggered) | ไม่มี |
| External integrations | SFTP, Puppeteer, ExcelJS | (none) | (none) | LDAP |
| Test coverage | 0% | ~moderate (มี e2e) | 0% | 0% |
| Doc | Swagger (auto) | Swagger + JSDoc | GraphQL schema | GraphQL schema |
| Production .env | Committed + baked | Externalized | Externalized | Externalized |
| Overall security | Bad | Bad (auth bypass) | OK | OK |
| Modernization debt | High | Low (service ใหม่) | High (legacy) | Critical (Node 12) |
Insights จากตาราง
- centralize-api เป็น NestJS รุ่นใหม่กว่าแต่ auth ไม่ทำงาน (
@Public()ทุก route) - benefit-api เป็น NestJS เช่นกัน แต่มี debt หนักกว่า centralize-api ทุกด้าน — เปรียบเหมือน "modernization" ที่ล้มเหลว เพราะ inherit pattern หลายอย่างจาก legacy (raw SQL,
sauser, cross-schema writes) - vtrc-api แม้เป็น GraphQL legacy แต่มี RBAC ที่ใช้งานได้ผ่าน
@authdirective — แข็งแรงกว่าทั้งสอง NestJS service ในด้าน authorization - cu-central-api ใช้ LDAP ทำให้ authentication แข็งแรงที่สุด แต่ runtime (Node 12) ใกล้ EOL
ข้อแนะนำเชิงกลยุทธ์
ระยะสั้น (1-3 เดือน) — หยุดเลือด
- Externalize secrets — ทำ S1, S3, S4 จาก 6.8 ทันที
- Parameterize raw SQL — เริ่มจาก Critical injection sites (2 จุด) แล้วทยอยทำที่เหลือ
- Remove
@Public()จาก mutation endpoints — quick win - DB user least-privilege — สร้าง dedicated user แม็พได้ grant เฉพาะ table ที่จำเป็น
ระยะกลาง (3-9 เดือน) — stabilize
- DTO + ValidationPipe — สร้าง DTO class สำหรับทุก endpoint
- TypeORM migrations — เปิด
TYPEORM_MIGRATIONS=true, version schema changes - Decouple
vtrc-common— pin version หรือ internalize utility ที่ใช้ - Add observability — metrics (Prometheus), tracing (OpenTelemetry), healthcheck
- Test setup — เริ่มจาก smoke test ของ critical path (payment flow, SFTP flow)
ระยะยาว (9-18 เดือน) — restructure
- Stop cross-schema writes — benefit-api ควรเรียก vtrc-api ผ่าน GraphQL ไม่ใช่เขียน DB ตรง (จัดการใน Volume 16 · Modernization Roadmap)
- Split monolithic service —
exportpaymentreport.service.ts7,740 บรรทัด → แยกเป็น module ย่อย (PDF gen, SFTP, query, transformation) - Consider bounded context — แยก "welfare request intake" จาก "disbursement/export" เป็น service คนละตัว
- Migrate to managed PDF service — Puppeteer + Chromium ใน container มี overhead สูง → AWS Lambda / Cloud Run job หรือ DOCRaptor
บทสรุปของ Volume 6
benefit-api เป็น service ที่มีขนาดเล็กในแง่จำนวน endpoints (~30) แต่มี debt สะสมหนักมากในด้าน security (Critical 6 รายการ), architecture (cross-schema writes), และ maintainability (monolithic service file, ไม่มี test)
service นี้เป็นตัวอย่างของ "modernization that inherited legacy patterns" — ใช้ NestJS/TypeScript รุ่นใหม่ แต่ preserve ปัญหาเดิมของ legacy (raw SQL, sa superuser, .env ใน git) เพราะ dev velocity ถูกเลือกไว้ก่อน hardening
เมื่ออ่านจบเล่มนี้ ควรเข้าใจ:
- โครงสร้าง codebase และวิธี navigate
- รูปแบบ raw SQL ที่อันตรายและจุด injection ทั้งหมด
- auth pipeline และจุดที่ bypass ได้
- การเชื่อมต่อกับ SFTP, HRMI, และ cron schedule
- รายการ debt ทั้งหมดพร้อม priority
ก่อนแก้ไขหรือเพิ่มฟีเจอร์ — อ่าน 6.8 ก่อนเสมอ
ไปต่อ
- Volume 7 · vtrc-web Deep Dive → — frontend ที่เรียก benefit-api
- Volume 10 · Security → — security เชิงลึกทั้งระบบ
- Volume 16 · Modernization Roadmap → — กลยุทธ์ปรับปรุง
- ย้อนกลับไปภาพรวม V1 →
- ย้อนกลับไปภาพรวม Volume →