tRPC هو الأفضل عندما يتحدث كامل المكدس بالفعل TypeScript_

يتم مدح tRPC كما لو كان يحل محل كل نمط من أنماط واجهات برمجة التطبيقات. لكنه لا يفعل.

ما يقوم به بشكل جيد هو إزالة أعمال التنسيق غير الضرورية داخل مكدس TypeScript المرتبط بشكل وثيق. إذا كان هناك تكامل قوي بين الواجهة الأمامية والخلفية، وكان كلاهما مكتوبًا بـ TypeScript، يمكن لـ tRPC تقليل الكثير من الكتابات المكررة والانجراف في الواجهات.

هذه ميزة حقيقية. لكنها ليست شاملة.

المشكلة التي يحلها

في العديد من تطبيقات TypeScript الكاملة، يتم وصف نفس العقد ثلاث مرات:

• التحقق من صحة المدخلات
• أنواع معالجات الخلفية
• أنواع مستهلكي الواجهة الأمامية

هذا التكرار هو المكان الذي تتسلل فيه الأخطاء والافتراضات القديمة.

يقوم tRPC بتقليص الكثير من ذلك من خلال السماح للعميل باستنتاج أنواع الإجراءات مباشرة من موجه الخادم:

import { initTRPC } from "@trpc/server";
import { z } from "zod";

const t = initTRPC.create();

export const appRouter = t.router({
  getUser: t.procedure
    .input(z.object({ id: z.string() }))
    .query(async ({ input }) => {
      return db.user.findById(input.id);
    }),
});

export type AppRouter = typeof appRouter;

على جانب العميل، لم تعد بحاجة إلى الحفاظ يدويًا على نسخة ثانية من العقد:

import { createTRPCProxyClient, httpBatchLink } from "@trpc/client";
import type { AppRouter } from "./server";

const trpc = createTRPCProxyClient<AppRouter>({
  links: [httpBatchLink({ url: "/api/trpc" })],
});

const user = await trpc.getUser.query({ id: "123" });

تلك هي الجزئية التي يحبها الناس: seams أقل مكتوبة يدويًا.

لماذا يبدو الأمر جيدًا جدًا

tRPC ممتاز عندما:

• يكون التطبيق مونو ريبوز أو يعادل قريب
• TypeScript هي اللغة على كلا الجانبين
• لا يُقصد من الواجهة الأمامية أن تكون مستهلكًا واسع النطاق لواجهة برمجة التطبيقات العامة

في ذلك العالم، تحصل على حلقة ردود فعل سريعة جدًا. قم بإعادة تسمية حقل على الخادم، وغالبًا ما تتعطل العميل في وقت الترجمة بدلاً من بعد أسبوع في QA.

التنازلات

tRPC أضعف عندما:

• يحتاج عدة لغات إلى استهلاك واجهة برمجة التطبيقات
• تكون واجهة برمجة التطبيقات عامة أو موجهة للشركاء
• تتطور الواجهة الخلفية والواجهة الأمامية بشكل مستقل
• تهم العقود على مستوى البروتوكول أكثر من راحة استنتاج الأنواع

في هذه الحالة، يكون REST أو gRPC عادة أكثر منطقية. ليس لأنهما أكثر حداثة، ولكن لأنهما أقل ارتباطًا.

إطار عمل أفضل

tRPC ليست "موت REST."

إنها مناسبة جدًا لفئة معينة من فرق المنتجات:

• منظمة واحدة
• مكدس واحد
• نظام نوع مشترك واحد

إذا كانت هذه هي حالتك، فهي خيار قوي.

إذا لم تكن كذلك، فإن فرض tRPC في الهندسة المعمارية عادةً ما يؤدي إلى مشكلة ارتباط من نوع مختلف.

قراءة إضافية

• توثيق tRPC
• توثيق Zod
• دليل TypeScript