Skip to content

13.1 · GraphQL APIs

มีเพียง 2 repository ในทั้งแพลตฟอร์ม (25 repo ที่มีโค้ด) ที่เปิด GraphQL API — ทั้งคู่อยู่ใน Legacy Core (Volume 3) และทั้งคู่ใช้ stack เดียวกัน (Apollo Server 2 + Express + hand-written SDL) ไม่มี domain microservice ตัวใดในกลุ่ม 2way/Domain/Meeting เปิด GraphQL ของตัวเองเลย — ทั้งหมดเลือก REST

13.1.1 · vtrc-api

ด้านค่า
Endpoint/api/graphql (prod), /api-uat/graphql (UAT)
FrameworkApollo Server 2 + Express
Schemahand-written SDL, 44 ไฟล์ใน typeDefs/
Resolver41 ไฟล์ + index.js ใน resolvers/
Subscriptionไม่มี — Query/Mutation เท่านั้น
Introspection ใน productionเปิดอยู่เสมอ (index.js:68-69) — ดู LEG-VTRC-API-01 ใน vtrc-api/10-scorecard

รายละเอียด pipeline เต็ม (5 gate ตั้งแต่ apiKey จนถึง menu ABAC) อยู่ใน vtrc-api/02-graphql-pipeline — สรุปสั้น:

Browser ─► Nginx ─► ApolloServer (Express)
                    ├─ context()       ← apiKey ต้องตรง API_DEVICE_KEY
                    ├─ @auth directive ← verifyToken + checkSession + checkMenuAuth
                    └─ resolver → controller → repository → Sequelize (MariaDB)

Auth header ที่ต้องส่ง

Headerความหมายอ้างอิง
Authorization: Bearer <jwt>JWT ที่ vtrc-api ออกตอน logindirectives/auth.js — ดู vtrc-api/03-auth-session
apiKeydevice key ที่ map เป็น APP_TYPE (WEB, MOBILE, WEB_ADMIN, …) — field ในโค้ดคือ key ไม่ใช่ apiKeyconfig.jsAPI_DEVICE_KEY — ดู Canonical Truths

frontend ทุกตัว (vtrc-web, vtrc-rc-backoffice, vtrc-backoffice, vtrc-backoffice-new, vtrc-mobile, new-vtrc-mobile) เลือก endpoint ผ่าน checkLinkURL() (web) หรือ constant ที่ comment/uncomment เอง (mobile) — ดูรายละเอียดที่ Canonical Truths § endpoint resolution

13.1.2 · cu-central-api

ด้านค่า
Endpoint/api/graphql
FrameworkApollo Server 2 + Express
Schema32 ไฟล์ SDL + index.js aggregator
Resolver28 ไฟล์ + index.js
Multi-tenancySourceDB sharding ทุก association — ไม่มีใน vtrc-api
Introspection ใน productiongate ด้วย IS_PRODUCTION flag (ดีกว่า vtrc-api)

รายละเอียดเต็มอยู่ใน cu-central-api/03-multitenancy-schema

Auth header ที่ต้องส่ง

Headerความหมาย
Authorization: Bearer <jwt>token ที่ cu-central-api หรือ vtrc-api (ผ่าน bridge) ออกให้
apiKey2-tier key — API_CENTRALIZE_KEY (default) หรือ API_CENTRALIZE_KEY_LEVEL_4 (elevated, ใช้เฉพาะ searchUserCD)

ใครเรียก cu-central-api ได้บ้าง (ยืนยันจากโค้ด) — ไม่ใช่แค่ vtrc-api ตามที่ตั้งสมมติฐานไว้เดิม (debt E-08) จริง ๆ มีผู้เรียกหลายทาง:

CallerQuery ที่เรียกหลักฐาน
vtrc-apiทุก query ผ่าน END_POINT_CENTRALIZEvtrc-api/04-centralize-bridge
2way-apifetchListEmployeeForTwoWay2way-api/03-persistence-integrations
2way-vtrc-apifetchListEmployeeForTwoWay (hardcode URL ต่างจาก 2way-api)2way-vtrc-api/03-persistence-integrations
meeting-vtrc-apifetchListEmployeeForTwoWay (ผ่าน cdbConnector)meeting-vtrc-api/03-persistence-integrations

query ชื่อ fetchListEmployeeForTwoWay ถูกเรียกจากอย่างน้อย 3 service ที่ไม่ใช่ 2way Platform โดยตรง (meeting-vtrc-api) ชื่อ query สื่อว่าตั้งใจให้ 2way ใช้ แต่กลายเป็น general-purpose employee-directory query ที่ทุก service ยืมใช้ — ดูรายละเอียดเต็มใน 13.3 Inter-service map

13.1.3 · centralize-api (NestJS) — ไม่มี GraphQL

centralize-api แม้ชื่อจะคล้าย cu-central-api มาก แต่เป็น REST ล้วน ไม่มี GraphQL — ดู 13.2 REST APIs

สรุปเปรียบเทียบ

ด้านvtrc-apicu-central-api
Apollo version2 (EOL)2 (EOL)
Subscriptionไม่มีไม่มี
DataLoader / batchingไม่มีไม่มี
Rate limitไม่มีไม่มี
Timeout ต่อ queryไม่มีไม่มี
Caller ที่ยืนยันแล้วfrontend ทั้งหมด (Volume 4/8)vtrc-api, 2way-api, 2way-vtrc-api, meeting-vtrc-api

ไม่มี service ใหม่ในแพลตฟอร์ม (2way Platform, Domain Microservices, Meeting Platform) เลือกเขียน GraphQL ของตัวเอง — ทุกตัวเลือก REST + NestJS/Express แม้ต้องคุยกับ cu-central-api (GraphQL) ก็ทำผ่าน GraphQL client ฝั่ง caller (เช่น graphql-request หรือ axios POST ตรง) ไม่ได้สร้าง GraphQL gateway ของตัวเอง