tRPC في TypeScript: تبسيط تطوير الـ API

بناء API يعني عادةً الاختيار بين REST أو GraphQL. تقضي وقتاً في إعداد المسارات (routes)، وإدارة المخططات (schemas)، ومزامنة الأنواع (types) بين الواجهة الأمامية (frontend) والواجهة الخلفية (backend). إذا كنت تستخدم TypeScript في كلا الطرفين، فستشعر أن هذه العملية ثقيلة، حيث ينتهي بك الأمر بكتابة الأنواع نفسها مرتين.

يغير tRPC سير العمل هذا؛ فهو يلغي الحاجة إلى عقد API (API contract) منفصل. بدلاً من ذلك، يستخدم TypeScript لمشاركة الأنواع تلقائياً بين الخادم (server) والعميل (client).

لماذا تستخدم tRPC؟

  • لا حاجة لمزامنة الأنواع يدوياً: تكتب دالة (function) على الخادم، ويعرف العميل أنواع المدخلات والمخرجات فوراً.
  • لا حاجة لتوليد الكود (code generation): لا تحتاج إلى تشغيل أدوات إضافية لإنشاء الأنواع.
  • لا يوجد انحراف في المخطط (schema drift): بما أن العميل يستخدم أنواع الخادم مباشرة، تظل الواجهة الأمامية متزامنة مع الواجهة الخلفية.
  • تطوير أسرع: تشعر وكأنك تستدعي دالة في ملف محلي بدلاً من إجراء طلب شبكة (network request).

للطرق التقليدية عيوب ومميزات (trade-offs). تتطلب REST استدعاءات fetch يدوية وأنواعاً مكررة. بينما يوفر GraphQL مخططاً (schema) ولكنه يضيف تعقيداً مع الـ resolvers والـ codegen.

يعامل tRPC الواجهة الخلفية الخاصة بك كمجموعة من الدوال الآمنة نوعياً (type-safe functions). تقوم بتعريف الإجراءات (procedures) في الموجهات (routers)، ثم يقوم العميل باستيراد نوع الموجه (router type) واستدعاء هذه الإجراءات مباشرة.

مثال على سير العمل:

  1. تعريف إجراء (procedure) على الخادم مع التحقق من الصحة (مثل Zod).
  2. تصدير نوع الموجه (router type).
  3. استدعاء ذلك الإجراء على العميل مع ميزة الإكمال التلقائي الكامل والأمان النوعي (type safety).

متى تستخدم tRPC:

  • عندما تستخدم كل من الواجهة الأمامية والواجهة الخلفية لغة TypeScript.
  • عندما تتحكم في كلا جانبي التقنيات (stack).
  • عندما تقوم ببناء أدوات داخلية، أو لوحات تحكم للمسؤولين (admin dashboards)، أو تطبيقات Next.js كاملة التقنيات (full-stack).
  • عندما تعمل في بيئة monorepo.

متى تتجنب tRPC:

  • عندما تقوم ببناء API عام لمستخدمين مختلفين كثر.
  • عندما يستخدم عملاؤك لغات مختلفة مثل Python أو Go.
  • عندما تحتاج إلى إصدارات معقدة للـ API (API versioning).

tRPC ليس بديلاً لـ REST أو GraphQL في كل السيناريوهات. إنه أداة للسرعة والأمان عندما تكون مجموعتك التقنية (stack) موحدة. فهو يزيل الاحتكاك الناتج عن حدود الـ API ويسمح لك بالتركيز على كتابة المنطق (logic).

المصدر: https://dev.to/geekyants/trpc-in-typescript-simplify-api-development-without-boilerplate-3lm3