ممکن است قبلاً با فریم‌ورک gRPC آشنا شده باشیم. با توجه به شباهتی که در نام‌گذاری وجود دارد این احتمال هست که tRPC و gRPC را به نوعی شبیه به هم در نظر بگیریم. اما این چنین نیست. هدف اصلی tRPC ارائه یک روش ساده و ایمن برای ایجاد API برای پروژه‌های مبتنی بر تایپ اسکریپت و جاوااسکریپت با حداقل footprint است. در این مقاله قصد داریم تا بیشتر با مفهوم tRPC آشنا شویم.

مروری بر مفاهیم  RPC، REST، GraphQL و tRPC

یکی از جنبه‌های کلیدی که توسعه‌دهندگان باید در حین ساختن برنامه‌های فول استک در نظر بگیرند، نحوه برقراری ارتباط میان فرانت‌اند و بک‌اند است. این تعامل از طریق APIها تسهیل می‌شود و چندین سبک معماری برای انتخاب وجود دارد. در این بخش مروری بر چهار مورد خواهیم داشت که عبارتند از: RPC، REST، GraphQL و tRPC.

RPC (Remote Procedure Call)

RPC پروتکلی است که یک برنامه می‌تواند از آن برای درخواست سرویس از برنامه‌ای که در یک شبکه بر روی کامپیوتر دیگری قرار دارد استفاده کند. در این پروتکل نیازی نیست که برنامه از جزئیات شبکه اطلاع داشته باشد. این فرآیند همانند فراخوانی تابعی است که روی دستگاه دیگری قرار دارد. پیاده‌سازی‌های زیادی از RPC وجود دارد از جمله gRPC، XML-RPC، و tRPC اما مفهوم کلی آن‌ها یکسان است: ما در حال فراخوانی یک procedure از یک ماشین remote هستیم.

REST (Representational State Transfer)

REST یک سبک معماری است که وب را هدایت کرده و استانداردی برای طراحی APIهای وب می‌باشد. در یک سیستم RESTful، منابع توسط URLها شناسایی می‌شوند و با استفاده از روش‌های HTTP مانند GET، POST، PUT، DELETE و غیره قابل دسترسی و دستکاری هستند. REST از ارتباطات stateless حمایت می‌کند. به این معنی که هر درخواست HTTP به طور مستقل انجام می‌شود و نیازی به اطلاع از درخواست‌هایی که قبلاً اتفاق افتاده است وجود ندارد.

GraphQL

GraphQL یک زبان کوئری برای APIها و یک زمان اجرا برای اجرای آن کوئری‌ها با داده‌های موجود است. این زبان به کلاینت اجازه می‌دهد تا ساختار داده‌های مورد نیاز را تعریف کند. سپس سرور دقیقاً داده‌هایی که کلاینت درخواست کرده است را برمی‌گرداند. انجام این کار می‌تواند کارآمدتر از APIهای RESTful باشد، جایی که سرور تعیین می‌کند چه داده‌هایی باید return شوند.

tRPC

tRPC یک فریم‌ورک خلاقانه از RPC است که به طور خاص طراحی شده است تا از استنتاج قدرتمند تایپ اسکریپت برای استخراج تعاریف تایپ یک روتر API استفاده کند. این کار به توسعه‌دهندگان اجازه می‌دهد تا procedureهای API را مستقیماً با ایمنی کامل تایپ و تکمیل خودکار، فراخوانی کنند که منجر به تجربه توسعه یکپارچه‌تر و کارآمدتر می‌شود.

بررسی tRPC

اگر برنامه‌ای داریم که هم در فرانت‌اند و هم در بک‌اند از تایپ اسکریپت استفاده می‌کند، مفهوم tRPC به ما کمک می‌کند تا API خود را به‌ گونه‌ای تنظیم کنیم که حداقل سربار را از نظر وابستگی‌ها و پیچیدگی زمان اجرا متحمل شود. با این حال، tRPC همچنان ایمنی تایپ و تمام ویژگی‌های همراه آن را فراهم می‌کند. مانند تکمیل خودکار برای کل API و خطاهایی برای زمانی که API به روشی نامعتبر مورد استفاده قرار می‌گیرد.

از نظر عملی، می‌توانیم tRPC را به عنوان جایگزینی بسیار سبک برای GraphQL در نظر بگیریم. با این حال، tRPC بدون محدودیت نیست. برای اولین بار، به تایپ اسکریپت و جاوااسکریپت محدود می‌شود. علاوه بر این، APIای که می‌سازیم و از مدل tRPC پیروی می‌کند، به این معنی است که یک REST API نخواهد بود. ما نمی‌توانیم یک REST API را به سادگی به یک tRPC تبدیل کنیم و همان API قبلی را داشته باشیم اما این بار تایپ‌ها را هم در آن گنجانده باشیم.

اساسا، tRPC یک راه حل batteries-included برای تمام نیازهای API ما است، اما یک tRPC-API نیز خواهد بود. این همان جایی است که نام RPC از آنجا می‌آید و نحوه کار فراخوانی‌های ریموت را تغییر می‌دهد. تا زمانی که از تایپ اسکریپت در gateway API خود استفاده کنیم، در مفهوم tRPC و استفاده از آن می‌تواند راه حل عالی برای ما باشد.

مقایسه tRPC و GraphQL

برای مقایسه مفهوم tRPC با GraphQL، می‌خواهیم چندین عامل کلیدی را باهم بررسی کنیم که عبارتند از:

• ایمنی تایپ (Type safety)
• عملکرد (performance)
• سادگی (simplicity)

Type safety

هر دو tRPC و GraphQL ایمنی تایپ را ارائه می‌دهند که برای حفظ پایگاه‌های عظیم کد، کاهش باگ‌ها و بهبود بهره‌وری توسعه‌دهندگان بسیار مهم است. با این حال، نوع ایمنی آن‌ها متفاوت می‌باشد:

• tRPC :tRPC ایمنی تایپ را از طریق تایپ اسکریپت و کتابخانه‌هایی مانند Zod برای اعتبارسنجی schema تامین کرده و امکان ایجاد domain objectها را فراهم می‌نماید. این‌ها می‌توانند شامل قوانین اعتبارسنجی باشند، بنابراین بررسی تایپ را با اعتبارسنجی واقعی ترکیب می‌کنند. در نتیجه این امکان را فراهم می‌کند تا ایمنی تایپ از بخش بک‌اند به بخش فرانت‌اند و همینطور لایه API حفظ گردد.
• GraphQL :GraphQL نیز از ایمنی تایپ پشتیبانی می‌کند، اما این کار را از طریق سیستم تایپ خود انجام می‌دهد. هنگامی که schemaی GraphQL را تعریف می‌کنیم، تایپ‌های داده‌هایی را که می‌توانیم پرس و جو کنیم، مشخص می‌نماییم. سپس از این تایپ‌ها برای اعتبارسنجی کوئری‌ها استفاده می‌شود. این باعث می‌شود تا مدیریت خطاها در مراحل اولیه و در طول زمان توسعه آسان‌تر شود

performance

مقایسه عملکرد بین tRPC و GraphQL را می‌توان با تفاوت‌های ظریفی انجام داد. زیرا این مقایسه‌ها به کاربرد خاص، نحوه طراحی و استفاده از API و بهینه‌سازی‌های خاص بستگی دارد:

• tRPC: هدف tRPC حداقل سربار از نظر وابستگی‌ها و پیچیدگی زمان اجرا است که به‌طور بالقوه سبک‌تر از GraphQL می‌باشد. با این حال، ویژگی‌های عملکرد می‌تواند به عوامل مختلفی مانند ماهیت داده‌های مورد استفاده، کارایی کد، شرایط شبکه و موارد دیگر بستگی داشته باشد.
• GraphQL :GraphQL به کلاینت‌ها اجازه می‌دهد دقیقاً آنچه را که نیاز دارند درخواست کنند، که می‌تواند با کاهش over-fetching برای عملکرد مفید باشد. با این حال، GraphQL می‌تواند به دلیل پیچیدگی حل کردن پرس و جوها در سمت سرور منابع فشرده‌تری داشته باشد، به خصوص اگر آن‌ها عمیقا تودرتو بوده و یا شامل روابط پیچیده بین موجودیت‌ها باشند.

simplicity

سادگی می‌تواند درونی بوده و به آشنایی توسعه‌دهنده با فناوری‌ها و مفاهیم مربوطه بستگی داشته باشد:

• tRPC: این فریم‌ورک به گونه‌ای طراحی شده است که برای توسعه‌دهندگان آشنا با تایپ اسکریپت، ساده و شهودی باشد. با این حال، مدل tRPC از اصول RESTful پیروی نمی‌کند. این موضوع ممکن است یک تغییر پارادایم برای توسعه‌دهندگانی باشد که به API های RESTful عادت دارند.
• GraphQL :GraphQL به دلیل انعطاف‌پذیری شناخته شده است. این امکان را به کلاینت‌ها می‌دهد تا داده‌هایی که نیاز دارند را دقیقا مشخص کنند. این موضوع می‌تواند مدیریت داده‌های سمت کلاینت را ساده‌تر کند. با این حال، منحنی یادگیری برای GraphQL می‌تواند به دلیل زبان پرس و جو منحصربه‌فرد آن و نیاز به مدیریت schemaها و resolverها، شیب بیشتری داشته باشد.

مقایسه tRPC و REST

tRPC و REST رویکردهای مختلفی را برای ساخت API ارائه می‌دهند. tRPC پیاده‌سازی API را به عنوان قرارداد تعریف می‌کند که API را ساده می‌کند اما برای تغییرات خاص نیاز به بازسازی فرانت‌اند و بک‌اند دارد. از سوی دیگر، REST از یک قرارداد جداگانه برای نشان دادن API استفاده می‌کند و تنها زمانی که قرارداد تغییر می‌کند نیاز به بازسازی ایجاد می‌شود.

در حالی که tRPC، APIها را همانطور که RPC فراخوانی می‌کند ساختار می‌دهد و یک API سمت کلاینت ساده‌تر ارائه می‌کند، ممکن است قابلیت پیش‌بینی APIهای REST را برای مصرف‌کنندگان تایپ اسکریپت یا عمومی از دست بدهد. REST ایمنی و قابلیت پیش‌بینی سیستم را با طراحی API معمولی و تماس‌های مشتری از نوع RPC بدون نیاز به لایه‌های انتزاعی اضافی حفظ می‌کند.

مقایسه tRPC و gRPC

tRPC و gRPC هر دو APIهای کلاینت و یا سرور ایمن را ارائه می‌دهند اما در بیشتر جنبه‌ها متفاوت عمل می‌کنند. gRPC از protobuf برای یک پروتکل compact wire با schemaهای تعریف‌شده در یک فایل protoاستفاده می‌کند. این فایل‌های protoکلاینت‌ها و یا سرورها را به زبان‌های مختلف (C++، Java، Go، Python) تولید می‌کنند.

از سوی دیگر، tRPC رویکردی متمایز دارد و schemaهای خود را مستقیماً در تایپ اسکریپت تعریف می‌کند، که سپس می‌تواند به صورت پویا توسط کلاینت و سرور import شود. این فریم‌ورک به اندازه gRPC بهینه نیست زیرا از HTTP استفاده می‌کند، اما استفاده از آن بسیار ساده‌تر است. برخلاف gRPC، tRPC که یک کتابخانه فقط تایپ اسکریپت است، web-native است یعنی برای کارکرد موثر در محیط مرورگر طراحی شده است.

جمع‌بندی

در این مقاله سعی کردیم تا بررسی کنیم که مفهوم tRPC چیست و چگونه می‌تواند در شرایطی که از تایپ اسکریپت هم در بخش فرانت‌اند و هم بک‌اند استفاده می‌کنیم مفید باشد.