پنج دلیل برای استفاده از Protocol Buffer بجای JSON -قسمت دوم

@appsaz_ir

پنج دلیل برای استفاده از Protocol Buffer بجای JSON -قسمت دوم

در قسمت قبل به معرفی پروتکل بافر پرداختیم و گریزی هم به نکاتی از JSON زدیم. در این مقاله در ادامه بحث قبلی پنج موردی را بررسی میکنیم که به شما توصیه میکند از پروتکل بافر به جای JSON استفاده کنید. با ما همراه باشید.

۱- طراحی فوق العاده

یک نکته حیاتی که وجود دارد این است که مهارت چیدمان مدل های داده در دیتابیس اهمیت بالایی دارد. همان لایه اصلی که در کد، مدل داده ای را نگه می دارد و سپس به لایه های بالاتر که قرار است با کاربر تعامل داشته باشد اجازه دسترسی به داده ها را بمنظور دریافت و یا ارسال اطلاعات به سرویس های دیگر میدهد. ما اغلب به کدهای نامطمئن در مرزهای سیستممان تکیه میکنیم که ممکن است بخشی از ساختار داده هایمان را که ممکن است مهم باشد را پوشش ندهد. بنابراین با استفاده از یکبار کدکردن موجودیت های سیستممان در قالب پروتکل گوگل می توانید مطمئن باشید که تمامی اطلاعات منتقل شده و هیچگونه داده ای در تعاملات بین اپلیکشن ها از دست نخواهد رفت.

۲- سازگاری برگشت پذیر

فیلدهایی که در تعریف پروتکل شماره گذاری شده اند نیاز به چک کردن ورژن های مختلف کد را برطرف کرده است که همین مورد یکی از دلایلی است که برای طراحی و پیاده سازی پروتکل گوگل به صراحت اعلام شده است. همانطور که در اسناد مربوط به توسعه دهندگان ذکر شده است “پروتکل بطور جزئی بمنظور اجتناب از کدهای نازیبا طراحی شده است.” کدهایی مثل تکه کد زیر:

با استفاده از فیلدهای شماره گذاری شده، شما هرگز مجبور نخواهید بود تا رفتار کدتان را برای حرکت بین لایه تعاملی و لایه داده ها در ورژن های قدیمی تغییر دهید. طبق اسناد معرفی پروتکل بافر “فیلد جدید می تواند به راحتی معرفی گردد و سرورهای واسط بدون این که نیاز باشد آن را بررسی کنند و یا در مورد سایر فیلد ها اطلاعی داشته باشند، آن را تجزیه و تحلیل و سپس از خود عبور دهند.” سرویس های چندگانه ای مثل JSON مشکلات متعددی دارند که مربوط به طراحی و پیچیدگی های کد پس زمینه است.

۳- کد کمتر

علاوه بر چک کردن ورژن ها و عدم پیچیدگی کد پس زمینه، JSON با اتکا بر کدهای دست نویس تعاملات خودش را انجام می دهد. دو کلاس Parser و Presenter که اغلب شامل لایه منطقی مخفی شده اند و ماهیت شکننده تجزیه هر نوع داده جدید را آشکار می کند. زمانیکه یک کلاس منطقی توسط پروتکل گوگل کدنویسی می شود، می تواند تمامی عمل هایی که JSON انجام می دهد را بدون دردسر پوشش دهد. همانطور که به تدریج طرخ و کد شما کامل می شود کلاس های شما نیز به موازات تولید خواهند شد که باعث تمرکز بیشتر روی کدتان و تولید محصولتان می شود.

۴- اعتبارسنجی و انعطاف پذیری

سه کلمه کلیدی required, optional و repeated در پروتکل بافر تعاریف قدرتمندی هستند. این عبارات امکان رمزگذاری لایه طراحی و شکل دهی به ساختار داده ها  همچنین پیاده سازی جزئیات مربوط به کارکرد کلاسها در هر زبانی را برای شما امکان پذیر میکند. کتابخانه پروتکل بافر استثناهایی را شامل می شود. بعنوان مثال وقتیکه بخواهید یک نمونه شیء را کد گذاری کنید که فیلدهای اجباری پر شده را نداشته باشد. شما همچنین می توانید ماهیت یک فیلد را بسادگی با تغییر یک فیلد جدید شماره گذاری شده از اجباری بودن به اختیاری بودن تغییر دهید یا بالعکس. داشتن اینچنین انعطاف پذیری ای باعث قدرتمندی پروتکل بافر شده است.

از آنجا که میتوان تعاریف پروتکل بافر را در میان سایر کدها تعبیه کرد، شما میتوانید یک ساختار کلی درخواست و پاسخ داشته باشید که اجازه انتقال ساختارهای داده به شکل کاملا انعطاف پذیری بین سرویس های مختلف را بدهد. سیستم های پایگاه داده هایی مثل Riak بدلیل همین قدرت از پروتکل بافر استفاده می کنند.

۵- سازگاری ساده زبان

بدلیل اینکه پروتکل بافر به زبان های مختلفی پیاده سازی شده اند قابلیت همکاری بین برنامه های چندزبانی را در معماری شما بسیار ساده تر می کنند. اگر شما سرویستان را با جاوا یا Go بنویسید و یا حتی بخواهید با کدی که با Node یا Clojure و یا Scala نوشته شده است ارتباط برقرار کنید فقط کافی است که فایل Proto خودتان را به زبان مقصد بنویسید و برخی استانداردهای مربوط به ایمنی و قابلیت همکاری را رعایت کنید.

چه زمانی استفاده از JSON مناسب است؟

در بعضی مواقع استفاده از JSON بهتر از موارد دیگری مثل پروتکل بافر است. مواردی از قبیل :

  • مواقعی که بخواهید و یا نیاز داشته باشید انواع داده ها توسط بشر قابل خواندن باشد.
  •  زمانیکه داده ها از سرویس به طور مستقیم توسط یک مرورگر وب مصرف شود.
  • زمانیکه برنامه سمت سرور شما با JavaScript نوشته شده باشد.
  • زمانیکه مدل داده ای شما هنوز به شکلی آماده نشده تا به یک طرح متصل شود.
  • زمانیکه پهنای باندی برای اضافه کردن یک ابزار جدید ندارید.
  • زمانیکه بار عملیاتی اجرای نوع دیگری از خدمات شبکه بسیار بزرگ باشد.

و موارد احتمالی دیگری. در نهایت مثل همیشه انتخاب پروتکل بافر و یا JSON وابسته به چیزی که در نظر دارید است.

نتیجه گیری

پروتکل بافر برای ارسال داده بین سرویس های داخلی نسبت به JSON چندین مزیت دارد. در حالی که جایگزین کاملی برای JSON نیست، مخصوصا برای خدماتی که به طور مستقیم توسط یک مرورگر وب استفاده میشود. پروتکل بافر مزایای بسیار بیشتری از آنچه که در بالا ذکر شد دارد، بلکه همچنین به طور معمول از لحاظ سرعت رمزگذاری و رمزگشایی، حجم اطلاعات منتقل شده و موارد دیگر، ارائه می دهد.

با توجه به آنچه که گفته شد اگر اکنون زمان انتخاب بین JSON و پروتکل بافر باشد، شما کدام یک را انتخاب میکنید؟ انتخاب و دلیل انتخابتان را با ما در میان بگذارید.

اگر این مطلب رو دوست داشتید، می تونید با دوستاتون به اشتراک بگذارید:

پاسخی بگذارید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *