เลือก REST หรือ GraphQL ตาม Use Case จริง
วิเคราะห์และตัดสินใจระหว่าง REST กับ GraphQL โดยพิจารณา query complexity, caching, ประสบการณ์ทีม และ tooling เพื่อให้ได้คำแนะนำที่ชัดเจนและ actionable ตรงกับบริบทโปรเจกต์จริง
คัดลอกพรอมต์ฉบับมีตัวแปร {{...}} ไปแก้ไขในเครื่องมือของคุณเอง
ตัวอย่างผลลัพธ์ที่จะได้
ก่อนเริ่มลงมือปรับพรอมต์ ดูตัวอย่างผลลัพธ์ที่คุณจะได้จริงเพื่อให้แน่ใจว่าพรอมต์นี้ตรงกับงานที่ต้องการ
1. คำตัดสินสั้น
ใช้ REST — CDN caching เป็นข้อกำหนดที่ GraphQL ตอบสนองได้ยาก และทีมยังไม่มีประสบการณ์ production GraphQL ซึ่งเพิ่มความเสี่ยงโดยไม่จำเป็น
2. วิเคราะห์ทีละปัจจัย
| ปัจจัย | คะแนน REST (1-5) | คะแนน GraphQL (1-5) | เหตุผล |
|---|---|---|---|
| Query complexity fit | 3 | 4 | GraphQL จัดการ multi-entity fetch และ field selection ได้ดีกว่า แต่ nested level ยังไม่ลึกพอที่จะ justify overhead |
| HTTP caching ease | 5 | 2 | CloudFront cache REST GET ได้ทันที GraphQL ส่วนใหญ่ใช้ POST ทำให้ CDN cache ไม่ได้โดยตรง |
| Team learning curve | 5 | 1 | ทีมรู้จัก REST ดี ไม่มี overhead เรื่อง schema, resolver, N+1 problem ในช่วง launch |
| Tooling ecosystem fit | 5 | 3 | AWS API Gateway + CloudFront ออกแบบมาสำหรับ REST โดยตรง |
| Over-fetching / under-fetching risk | 3 | 5 | Mobile กับ web ต้องการ field ต่างกัน GraphQL แก้ปัญหานี้ได้ดีกว่า |
| Schema versioning & evolution | 4 | 4 | ทั้งคู่จัดการได้ดี REST ใช้ URL versioning ง่าย GraphQL มี deprecation built-in |
ปรับให้เข้ากับงานของคุณ
แก้ค่าตัวแปรด้านล่าง พรอมต์ฉบับสมบูรณ์จะอัปเดตอัตโนมัติ พร้อมคัดลอกไปวางใน Claude หรือ ChatGPT ได้ทันที
อธิบาย use case หรือ project ของคุณสั้นๆ 1-3 ประโยค
บอก query complexity เช่น ง่าย (CRUD ล้วน), ปานกลาง (nested 2-3 ชั้น), หรือซับซ้อน (deeply nested, real-time)
บอกความสำคัญและ type ของ caching เช่น CDN caching, in-memory cache, หรือไม่ต้องการ
ระบุขนาดทีมและระดับประสบการณ์กับ REST และ GraphQL
ระบุ infrastructure และ tooling ที่ใช้อยู่แล้ว เช่น cloud provider, framework, API gateway
## Project context
- **Use case**: แอป e-commerce ที่มี mobile และ web client ต้องการข้อมูล product, inventory, และ user ในหน้าเดียวกัน แต่แต่ละ client ต้องการ field ต่างกัน
- **Query complexity**: ปานกลาง — หน้า product detail ดึง 4-5 entities ที่ nested กัน แต่ส่วนใหญ่ยัง CRUD ปกติ
- **Caching requirements**: สำคัญมาก — ต้องการ CDN caching สำหรับ product catalog ที่อ่านบ่อย
- **Team experience**: ทีม 5 คน คุ้นเคย REST ดีมาก ไม่มีใครเคยทำ GraphQL ใน production
- **Existing tooling / infrastructure**: AWS API Gateway, CloudFront CDN, Node.js/Express backend
## Task
Analyse the trade-offs between REST and GraphQL for the project context above, then deliver a structured recommendation.
## Rules
- Be direct. State a clear recommendation.
- Do not recommend GraphQL just because it is newer or trendier.
- If the use case is primarily simple CRUD with low query complexity, REST is almost always correct — say so plainly.
- Do not hedge every sentence with "it depends."
- Respond in Thai, using English only for technical terms, API names, and code snippets.
## Output format
### 1. คำตัดสินสั้น (1-2 ประโยค)
ระบุ technology ที่แนะนำและเหตุผลหลักโดยย่อ
### 2. วิเคราะห์ทีละปัจจัย
สร้าง Markdown table พร้อม column: ปัจจัย | คะแนน REST (1-5) | คะแนน GraphQL (1-5) | เหตุผล
ปัจจัยที่ต้องประเมิน:
- Query complexity fit
- HTTP caching ease
- Team learning curve
- Tooling ecosystem fit
- Over-fetching / under-fetching risk
- Schema versioning & evolution
### 3. Risk flags (สูงสุด 3 ข้อ)
ระบุความเสี่ยงเฉพาะของ technology ที่แนะนำในบริบทนี้
### 4. Hybrid / escape-hatch option
ถ้า hybrid approach (เช่น REST สำหรับ public endpoints + GraphQL สำหรับ internal) หรือ migration path มีความเหมาะสม ให้อธิบาย 2-3 ประโยค ถ้าไม่จำเป็นให้เขียน "ไม่จำเป็น"
### 5. Next step ที่ทำได้ทันที
ขั้นตอนที่ทีมทำได้ภายในสัปดาห์นี้ (1 ข้อเท่านั้น)
เข้าใจเทคนิคที่ซ่อนอยู่
คลิกที่ส่วนไฮไลต์ในพรอมต์เพื่อกระโดดไปดูคำอธิบายเทคนิคแต่ละจุด ใช้ความเข้าใจนี้เพื่อปรับพรอมต์อื่นของคุณเองในภายหลัง
## Project context
- **Use case**: {{use_case}}
- **Query complexity**: {{query_complexity}}
- **Caching requirements**: {{caching_requirement}}
- **Team experience**: {{team_experience}}
- **Existing tooling / infrastructure**: {{tooling}}2
## Task
Analyse the trade-offs between REST and GraphQL for the project context above, then deliver a structured recommendation.
## Rules
- Be direct. State a clear recommendation.
- Do not recommend GraphQL just because it is newer or trendier.3
- If the use case is primarily simple CRUD with low query complexity, REST is almost always correct — say so plainly.
- Do not hedge every sentence with "it depends."
- Respond in Thai, using English only for technical terms, API names, and code snippets.
## Output format
### 1. คำตัดสินสั้น (1-2 ประโยค)
ระบุ technology ที่แนะนำและเหตุผลหลักโดยย่อ
### 2. วิเคราะห์ทีละปัจจัย
สร้าง Markdown table พร้อม column: ปัจจัย | คะแนน REST (1-5) | คะแนน GraphQL (1-5) | เหตุผล4
ปัจจัยที่ต้องประเมิน:
- Query complexity fit
- HTTP caching ease
- Team learning curve
- Tooling ecosystem fit
- Over-fetching / under-fetching risk
- Schema versioning & evolution
### 3. Risk flags (สูงสุด 3 ข้อ)
ระบุความเสี่ยงเฉพาะของ technology ที่แนะนำในบริบทนี้
### 4. Hybrid / escape-hatch option
ถ้า hybrid approach (เช่น REST สำหรับ public endpoints + GraphQL สำหรับ internal) หรือ migration path มีความเหมาะสม ให้อธิบาย 2-3 ประโยค ถ้าไม่จำเป็นให้เขียน "ไม่จำเป็น"
### 5. Next step ที่ทำได้ทันที
ขั้นตอนที่ทีมทำได้ภายในสัปดาห์นี้ (1 ข้อเท่านั้น)5
แตะส่วนที่ไฮไลต์เพื่อดูคำอธิบายเทคนิคแต่ละจุด · {{ }} คือตัวแปรที่ปรับได้
"You are a senior software architect with 10+ years of experience designing APIs in both REST and GraphQL at scale."
การกำหนดบทบาทที่เจาะจงทั้ง seniority และประสบการณ์เฉพาะด้านทำให้โมเดลใช้กรอบคิดของ architect ที่เคยใช้ทั้งสองระบบจริง ไม่ใช่แค่ตอบจากเอกสารทั่วไป
"## Project context - **Use case**: {{use_case}} - **Query complexity**: {{query_complexity}} - **Caching requirements**: {{caching_requirement}} - **Team experience**: {{team_experience}} - **Existing tooling / infrastructure**: {{tooling}}"
การให้ context ครบทั้ง 5 มิติบังคับให้โมเดลวิเคราะห์ตาม situation จริงของทีม แทนที่จะตอบแบบ generic ที่ไม่นำไปสู่การตัดสินใจได้
"Do not recommend GraphQL just because it is newer or trendier."
การห้ามอย่างชัดเจนป้องกัน recency bias ที่โมเดลมักมีต่อเทคโนโลยีใหม่ ทำให้คำแนะนำตั้งอยู่บนข้อเท็จจริงของโปรเจกต์ ไม่ใช่ความนิยม
"สร้าง Markdown table พร้อม column: ปัจจัย | คะแนน REST (1-5) | คะแนน GraphQL (1-5) | เหตุผล"
การกำหนด format เป็น table พร้อม scoring 1-5 บังคับให้โมเดลเปรียบเทียบอย่างเป็นระบบทุกปัจจัย ผู้อ่านเห็นตัวเลขเทียบกันได้ทันทีและตัดสินใจง่ายขึ้น
"### 5. Next step ที่ทำได้ทันที ขั้นตอนที่ทีมทำได้ภายในสัปดาห์นี้ (1 ข้อเท่านั้น)"
การบังคับให้ output ลงท้ายด้วย next step ที่ทำได้จริงเพียง 1 ข้อทำให้การวิเคราะห์แปลงเป็น action ทันที ไม่ใช่แค่ report ที่อ่านแล้วยังไม่รู้จะเริ่มจากไหน
เห็นความต่างระหว่างพรอมต์ทั่วไปกับพรอมต์ที่ใช้เทคนิค
คนส่วนใหญ่เริ่มต้นด้วยคำสั่งสั้น ๆ แบบพรอมต์ที่ใช้กันทั่วไป แต่ผลลัพธ์มักไม่ตรงใจและต้องถามซ้ำหลายรอบ พรอมต์แบบที่ใช้เทคนิคข้างต้นช่วยแก้ปัญหานี้
REST หรือ GraphQL ดีกว่ากัน?
กำหนด role architect ที่มีประสบการณ์จริง + ให้ context ครบ 5 มิติ (use case, query complexity, caching, team, tooling) + ห้าม recency bias + บังคับ output เป็น table scoring พร้อม verdict และ next step ที่ทำได้ภายในสัปดาห์
