35 : 42 : 15
مانده تا پایان تخفیف
فقط تا آخر امروز
فقط امروز
علی شکرالهی
بنیانگذار توسینسو و توسعه دهنده

gPRC چیست و چه تفاوتی با HTTP API مبتنی بر JSON دارد؟

gRPC یک سیستم متن باز RPC (Remote Procedure Call) هست که در سال 2015 توسط گوگل توسعه داده شده.در این روش ، برنامه ی کلاینت بطور مستقیم توابع موجود در سرور رو که میتونه روی یه کامپیوتر دیگه قرار گرفته باشه رو فراخونی میکنه که این مسئله کمک میکنه که بتونیم برنامه های توزیع یافته رو ایجاد و مدیریت کنیم.مشابه سیستم های rpc ، این سیستم هم مبتنی بر این ایده کار میکنه که ابتدا ساختار سرویس ها و توابع اونها که بصورت ریموت قابل فراخوانی هستند تعریف میشه .

+ سرفصل های این مطلب
  1. تفاوت gRPC و HTTP Api
  2. نقاط قوت gRPC
  3. تعیین Deadline یا timeout
  4. موارد مناسب جهت استفاده از gRPC
  5. ضعف های gRPC
    1. پشتیبانی محدود مرورگرها
    2. عدم خوانایی آسان داده ها
مجموعه دوره آموزش برنامه نویسی - مقدماتی تا پیشرفته
برای شروع آموزش برنامه نویسی کلیک کن

سپس در سمت سرور ، این واسط (Interface) پیاده سازی میشه و یک سرور gRPC راه اندازی میشه تا درخواست های ارسالی از سمت کلاینت ها رو پردازش کنه .در سمت کلاینت ، ما مفهومی به نام Stub داریم که در برخی زبانها همون کلاینت میشه ، که متدها و سرویس های پیاده سازی شده در سمت سرور رو برای کلاینت ارائه میدن تا امکان فراخونیشن فراهم بشه.

gPRC چیست و چه تفاوتی با HTTP API مبتنی بر JSON دارد؟

سرور ها و کلاینت های gRPC میتونن در محیط های متفاوت و مختلف از هم  با یکدیگر در ارتباط باشن . مثلا شما میتونین سرور رو با زبان سی شارپ پیاده کنین و کلاینت ها  از طریق سایر زبان ها مثل جاوا، Go ، JavaScript و ... با سرور در ارتباط باشن

تفاوت gRPC و HTTP Api

انتخاب تکنولوژی پیاده سازی Api جهت استفاده در سیستم نرم افزاری ، یکی از مهمترین بخش های توسعه سیستم می باشد.gRPC در مقایسه با HTTP API مزیت های مختلفی را ارائه میدهد که در ذیل به بررسی اجمالی اونها میپردازیم

ویژگی

gRPC

Http Apis With JSON

Contract ( قرارداد)

نیاز به .proto

اختیاری (OpenAPI)

پروتوکل

HTTP/2

HTTP

Payload

Protobuf(کم حجم، باینری)

JSON(حجم بالا، قابل خواندن)

Prescriptiveness (تجویز)



Streaming

Client، Server ، Bi-Directional

Client,Server

پشتیبانی از مرورگرها

خیر

بله

امنیت (Security)

Transport(TLS)

Transport(TLS)

تولید کد مشتری

بله

OpenAPI + third party tooling


نقاط قوت gRPC

  • سرعت و  عملکرد :پیامهای ارسالی در gRPC با استفاده از protobuf که یک فرمت بهینه باینری هست serialize میشن. Protobuf هم سمت سرور و هم سمت کلاینت ، عملیات serialize رو بسرعت انجام میده . همینطور استفاده از protobuf باعث ایجاد payload های کم حجم در ارسال و دریافت اطلاعات میشه که در مواردی مانند اپلیکیشن های موبایلی که مسئله ی پهنای باند اهمیت زیادی داره باعث بهبود عملکرد میشه .همینطور gRPC برای http/2 که یک نسخهی بهبود یافته از http هست طراحی شده که دارای بهبودهای زیادی در زمینه عملکرد و سرعت داره .
  • تولید کد (Code Generation) : تمام فریم ورک های gRPC از این امکان پشتیبانی میکنند . در زمان توسعه ی gRPC فایل .proto هسته ی اصلی کار را تشکیل میدهد که در واقع قرارداد (Contract) یی هست که پیام ها و سرویس های gRPC را مشخص میکند . از طریق این فایل تمام فریم ورکهایی gRPC کلاس های پایه ، پیام ها و کلاس های client را ایجاد میکنند .با به اشتراک گذاری فایل .proto بین سرور و کلاینت ، امکان ایجاد فایلهای یکپارچه و یکسان در کمترین زمان ممکن میسر می شود .
  • ساختار و تعریف مشخص (Strict Specification) : برخلاف http api با استفاده از json که از ساختار و الگوی مشخصی پیروی نمیکنه و توسعه دهندگان تنها با رعایت یک سری موارد همچون http verb ها و ... کار رو پیش میبرن ، gRPC با الزام یک فرمت و ساختار مشخص و ثابت در بین تمام پلتفورم ها و پیاده سازی ها ، باعث کاهش زمان توسعه و افزایش بهره وری توسعه دهندگان می شود .
  • Streaming : پروتکلhttp/2 امکان برقراری یک ارتباط پایدار و realtime را فراهم میکند که gRPC با بهره گیری از امکانات http2 از این قابلیت پشتیبانی می کند .سرویس gRPC تمام ترکیب های  streaming زیر را پشتیبانی میکند :
  1. Unary
  2. Server to Client
  3. Client to Server
  4. Bi-Directional

تعیین Deadline یا timeout

در gRPC این امکان برای کلاینت فراهم هست تا بتونه مشخص کنه که چه مدت زمانی مایل هست برای پایان یک درخواست rpc منتظر بمونه تا به پایان برسه . deadline به سرور ارسال میشه و سرور میتونه تصمیم بگیره که در صورت گذشتن زمان مربوطه و عدم اتمام کار، چه کاری انجام بده . برای مثال ممکن هست سرور با پایان deadline مربوطه، عملیات های درحال انجام رو کنسل کنه .

موارد مناسب جهت استفاده از gRPC

  1. Microservice ها : معماری gRPC بگونه ای طراحی شده تا برای ارتباطات با تاخیر کم و خروجی بالا استفاده بشه.
  2. ارتباطات نقطه به نقطه و realtime : gRPC پشتیبانی کاملی از bi-directional streaming داره و سرویس های ایجاد شده با grpc میتونین بدون استفاده از pooling پیام ها رو بصورت realtime ارسال کنن
  3. محیط های چندضلعی :ابزارهای grpc ، از اکثر زبان های محبوب و پرکاربرد پشتیبانی میکنه که همین مسئله grpc رو یک گزینه ی مناسب در محیط های توسعه چند زبانه میکنه .
  4. شبکه های محدود : بدلیل Serialize شدن پیام های grpc با استفاده از protobuf و کم حجم بودن و کوچکتر بودن اطلاعات ارسالی در مقایسه با json ، این روش گزینه ی مناسبی در شبکه های با محدودیت های از قبیل پهنای باند می باشد .

ضعف های gRPC

پشتیبانی محدود مرورگرها

در حال حاضر مرورگها بطور کامل از ویژگی های ارائه شده توسط http/2 پشتیبانی نمیکنن . که جهت استفاده از این تکنولوژی بایستی از GRPC-Web که توسط تیم grpc ارائه شده استفاده کنین.همینطور در حال حاضر تمام ویژگی های grpc مثل bi-directional توسط grpc-web پشتیبانی نمیشه .

عدم خوانایی آسان داده ها

بدلیل Serialize شدن اطلاعات توسط protobuf و باینری بودن داده های ارسالی ، امکان خواندن اطلاعات مثل اطلاعات json نمی باشد.

1 4
علی شکرالهی

بنیانگذار توسینسو و توسعه دهنده

علی شکرالهی، بنیانگذار TOSINSO ، توسعه دهنده وب و برنامه نویس موبایل، مهندسی نرم افزار از دانشگاه آزاد اسلامی واحد کرج ، بیش از 15 سال سابقه ی فعالیت های حرفه ای و آموزشی

نظرات