ปัญหาที่ tRPC แก้ไข

เมื่อคุณสร้าง REST API ด้วย TypeScript เซิร์ฟเวอร์จะเป็นผู้กำหนดรูปแบบการตอบกลับ ไคลเอนต์ต้องสร้างประเภทข้อมูล TypeScript ที่ตรงกันด้วยตนเอง ประเภทข้อมูลเหล่านี้จะค่อย ๆ คลาดเคลื่อนเมื่อ API พัฒนาไป และคอมไพเลอร์ไม่สามารถตรวจพบความไม่ตรงกันได้ เพราะประเภทข้อมูลถูกกำหนดไว้ในแพ็กเกจที่แยกจากกัน

การเปลี่ยนชื่อฟิลด์บนเซิร์ฟเวอร์จะกลายเป็นข้อผิดพลาดขณะทำงานบนไคลเอนต์โดยไม่มีการแจ้งเตือน

GraphQL แก้ปัญหาประเภทข้อมูลคลาดเคลื่อนด้วยการสร้างประเภทข้อมูล TypeScript จากสคีมาโดยใช้เครื่องมืออย่าง graphql-codegen วิธีนี้ทำงานได้ดี แต่เพิ่มความซับซ้อน ได้แก่ ภาษาสำหรับเขียนคิวรีที่แยกต่างหาก (GraphQL SDL) ขั้นตอนสร้างโค้ดในกระบวนการสร้าง และเครื่องมือจัดการสคีมา

สำหรับทีมที่ลงทุนกับ GraphQL อยู่แล้ว codegen คือคำตอบที่เหมาะสม สำหรับทีมที่ต้องการความปลอดภัยด้านประเภทข้อมูลโดยไม่ต้องรับภาระของ GraphQL tRPC เป็นทางเลือกหนึ่ง

แนวทางของ tRPC เรียบง่ายอย่างมาก นั่นคือกำหนดโพรซีเยอร์ API บนเซิร์ฟเวอร์เป็นฟังก์ชัน TypeScript ส่งออกประเภทของเราเตอร์ แล้วนำเข้าประเภทนั้นบนไคลเอนต์ ไม่ต้องสร้างโค้ด และไม่ต้องใช้ภาษาสคีมาแยกต่างหาก

คอมไพเลอร์ TypeScript เองจะบังคับใช้ข้อตกลงระหว่างไคลเอนต์กับเซิร์ฟเวอร์ในเวลาสร้าง

tRPC ต้องให้เซิร์ฟเวอร์และไคลเอนต์แชร์ประเภทข้อมูลผ่านการนำเข้า TypeScript วิธีนี้ทำงานได้เป็นธรรมชาติในโมโนรีโป (Turborepo, Nx, pnpm workspaces) ซึ่งเซิร์ฟเวอร์และไคลเอนต์เป็นแพ็กเกจแยกกันที่สามารถนำเข้าจากกันและกันได้

สำหรับแบ็กเอนด์และฟรอนต์เอนด์ที่แยกจากกันโดยสมบูรณ์ คุณจะต้องเผยแพร่ประเภทของเราเตอร์เป็นแพ็กเกจที่ใช้ร่วมกัน ซึ่งเพิ่มขั้นตอนการเผยแพร่ แต่ยังคงไม่ต้องสร้างโค้ดอัตโนมัติ

บนเซิร์ฟเวอร์ คุณกำหนดเราเตอร์และส่งออกประเภทของเราเตอร์ดังนี้: export type AppRouter = typeof appRouter บนไคลเอนต์ คุณนำเข้าประเภทนั้นและสร้างไคลเอนต์ที่มีประเภทข้อมูลดังนี้: createTRPCReact() ไคลเอนต์จะทราบอย่างชัดเจนว่ามีโพรซีเยอร์ใดบ้าง รวมถึงประเภทข้อมูลอินพุตและเอาต์พุตของแต่ละโพรซีเยอร์

เมื่อเปลี่ยนชื่อโพรซีเยอร์บนเซิร์ฟเวอร์ คอมไพเลอร์ TypeScript จะแสดงข้อผิดพลาดบนไคลเอนต์ทันที

เนื่องจาก tRPC ใช้ระบบประเภทข้อมูลของ TypeScript โดยตรง โปรแกรมแก้ไขโค้ดของคุณจึงมีการเติมโค้ดอัตโนมัติอย่างครบถ้วนสำหรับชื่อโพรซีเยอร์ รูปแบบอินพุต และประเภทข้อมูลที่ส่งคืนบนฝั่งไคลเอนต์ การเปลี่ยนชื่อโพรซีเยอร์เป็นการปรับโครงสร้างด้วยคำสั่งเปลี่ยนชื่อของ TypeScript ไม่ใช่การค้นหาและแทนที่ด้วยตนเองทั่วทั้งโค้ดเบส

ในทางปฏิบัติ การปรับปรุงประสบการณ์ของนักพัฒนานี้คือฟีเจอร์ที่ได้รับคำชื่นชมมากที่สุดของ tRPC

โดยค่าเริ่มต้น tRPC ใช้ HTTP เป็นรูปแบบการส่งข้อมูล การเรียกโพรซีเยอร์แต่ละครั้งจะเป็นคำขอ HTTP tRPC ยังรองรับ WebSockets สำหรับการสมัครรับข้อมูล รูปแบบการส่งข้อมูลถือเป็นรายละเอียดในการนำไปใช้งาน ส่วน API ของไคลเอนต์จะเหมือนเดิมไม่ว่าจะใช้รูปแบบใด

คุณยังสามารถเปิดเผยโพรซีเยอร์ของ tRPC เป็นปลายทาง REST แบบทั่วไปได้ โดยใช้อะแดปเตอร์ REST เพื่อให้ทำงานร่วมกับไคลเอนต์ที่ไม่ใช่ tRPC

tRPC ทำงานเป็นมิดเดิลแวร์ใน Express, Fastify และ Hono สำหรับ Next.js ระบบจะผสานรวมผ่านตัวจัดการเส้นทาง API ส่วนตัวเริ่มต้น create-t3-app (T3 Stack) รวม tRPC, Prisma, NextAuth และ Tailwind ไว้ในแม่แบบ Next.js แบบฟูลสแต็ก

T3 Stack เป็นจุดเริ่มต้นของ tRPC ที่ได้รับความนิยมสูงสุด และแสดงรูปแบบการพัฒนาที่พร้อมใช้งานจริง

อีกแนวทางหนึ่งของ REST ที่ปลอดภัยด้านประเภทข้อมูลคือการกำหนดสคีมา Zod สร้างข้อกำหนด OpenAPI โดยอัตโนมัติ และสร้างประเภทข้อมูล TypeScript จากข้อกำหนดนั้น วิธีนี้ทำให้ได้ข้อตกลง API ที่ไคลเอนต์ซึ่งไม่ใช่ TypeScript สามารถใช้งานได้

tRPC เรียบง่ายกว่าแต่ใช้ได้เฉพาะ TypeScript ส่วน OpenAPI+Zod เพิ่มความซับซ้อน แต่สร้างข้อตกลง API สาธารณะได้ เลือก tRPC สำหรับการสื่อสารภายในระหว่าง TypeScript กับ TypeScript และเลือก OpenAPI สำหรับ API สาธารณะ

tRPC ไม่ใช่สิ่งทดแทน REST เมื่อคุณต้องการ API สาธารณะที่บุคคลภายนอกใช้ ไคลเอนต์มือถือที่ไม่ได้เขียนด้วย TypeScript หรือพาร์ตเนอร์ที่ต้องการข้อตกลงแบบมีเวอร์ชันและมีเสถียรภาพ tRPC ออกแบบมาโดยเฉพาะสำหรับโมโนรีโป TypeScript ที่ต้องการความปลอดภัยด้านประเภทข้อมูลแบบฟูลสแต็ก

การเข้าใจขอบเขตนี้ช่วยป้องกันการนำ tRPC ไปใช้ในบริบทที่ REST หรือ GraphQL เหมาะสมกว่า

การรันคำสั่ง npm create t3-app@latest จะสร้างโครงร่างโครงการ Next.js ที่ตั้งค่า tRPC, Prisma, NextAuth.js, Tailwind CSS และ TypeScript ไว้ล่วงหน้า โค้ดที่สร้างขึ้นแสดงโครงสร้างเราเตอร์ การสร้างบริบท และการตั้งค่าไคลเอ็นต์

การศึกษาโครงร่างนี้เป็นวิธีที่รวดเร็วที่สุดในการทำความเข้าใจว่าส่วนประกอบทั้งหมดของ tRPC ทำงานร่วมกันอย่างไรในแอปพลิเคชันจริง

tRPC แบ่งปันชนิดข้อมูลระหว่างเซิร์ฟเวอร์กับไคลเอ็นต์โดยไม่ต้องสร้างโค้ดได้อย่างไร

tRPC แก้ปัญหาชนิดข้อมูลระหว่างไคลเอ็นต์กับเซิร์ฟเวอร์ของ TypeScript ไม่ตรงกัน ด้วยการนำเข้าชนิดข้อมูล TypeScript ของเราเตอร์โดยตรง จึงไม่ต้องสร้างโค้ด ทำงานได้ในโมโนเรโป และผสานการทำงานกับ Next.js, Express, Fastify และ Hono ได้ ส่วน T3 Stack (create-t3-app) เป็นชุดเริ่มต้นมาตรฐานสำหรับการใช้งานจริง

tRPC ใช้ได้เฉพาะกับ TypeScript และเหมาะที่สุดสำหรับแอปพลิเคชันฟูลสแตกภายใน ไม่ใช่ API สาธารณะ