مقایسه جنگو و روبی
بلاگ آکادمی لرن فایلز
طرح تخفیف «به افتخار کوروش بزرگ» فعال شد با ۷۵و۸۵ درصد تخفیف-۴۸ساعته
دریافتبلاگ آکادمی لرن فایلز
وقتی به دنبال یک فریم ورک برای توسعه ی برنامه های خود هستیم، باید به عملکرد آن ها توجه زیادی داشته باشیم. برنامه نویس های جوان معمولا مقایسه های زیادی بین روبی و جنگو به عنوان دو فریم ورک معروف انجام می دهند.
این مقاله برای افراد مبتدی و کسانی که به دنبال تصمیم گیری بین این دو فریم ورک هستند نوشته شده است. در این مطلب مقایسه جنگو و روبی و عملکرد آن ها را بررسی می کنیم.
جنگو یک فریم ورک برنامه نویسی تحت وب است که در سال ۲۰۰۵ انتشار یافت. این فریم ورک با هدف سرعت بخشیدن به توسعه ی وب سایت های خبری ایجاد شده بود اما در طول زمان به یک فریم ورک کامل برای همه نوع کاربری تبدیل شد. برنامه های معروف زیادی در جنگو نوشته شده اند. اینستاگرام، BitBucket و Pinterest. تا ژانویه ۲۰۱۷، ۱۳۵۰ شریک جنگو در Guthub کد های خود را به اشتراک گذاشته بودند.
این فریم ورک که به اصلاح ” باتری سر خود” نیز خوانده می شود، در خود ORM ، Admin UI، ورود به سیستم و مدیرت Session ها و سایر ابزارها را دارد.
اصول معماری هسته ای در جنگو بر مبنای اصول پایتون می باشد: یعنی ” خوانش مهم است” و ” صراحت مهم تر است از تعهد”. کد های جنگو براحتی خوانده شده و روش کاری و اجرایی کد ها بسیار راحت و مشخص است.
روبی در سال ۲۰۰۸ منتشر شد. این فریم ورک در ۳۷ سیگنال برای تواندهی به پروژه ها ایجاد شده است. روبی خیلی زود محبوبیت یافت و حتی بیشتر از جنگو مورد توجه قرار گرفت. روبی، سایت های زیادی را پشتبانی می کند : Fivvrr و Github و AirBnB. تا ژانویه ی سال ۲۰۱۷، ۳۲۲۴ شریک روبی در Github کد های خود را قرار داده اند. مثل جنگو، روبی تمامی ابزار های خوب را برای کار بهتر با برنامه های مبتنی بر پایگاه داده فراهم می کند.
روبی دنبال کننده ی اصلی “راحتی بر پیکربندی ارجحیت دارد” فعالیت می کند؛ یعنی شما نسبت به جنگو کدهای کم تری می نویسید، ولی همیشه مشخص نیست که کار ها به چه شکل رخ می دهند و چگونه باید آن ها ویرایش کرد.
بیایید این دو فریم ورک را با هم در یک جدول مقایسه کنیم.
روبی | جنگو | |
سال تولید | ۲۰۰۵ | ۲۰۰۸ |
حقوق متوسط برنامه نویس | ۸۸.۵۵۴ دلار | ۸۶.۸۰۱دلار |
تعداد کار های ممکن | ۵۱۲ | ۲۸۱ |
الگو | MVC | Model-template |
تمپلیت | <%= link_to "Show", book %> | Show |
وقتی من شروع به یادگیری برنامه نویسی تحت وب کردم، برای من عملکرد بهینهی فریم ورک و سرعت زبان برنامه نویسی مهم ترین گزینه ها بودند. حتی در یک دوره من از زبان برنامه نویسی haskell به خاطر سرعتش استفاده می کردم. حالا که ده سال گذشته، برای من کاملا واضح است که فقط سرعت زبان برنامه نویسی و فریم ورک ملاک نیستند، بلکه عملکرد کلی و موفقیت نهایی آن هاست که تعیین کننده می باشد.
با نگاهی به جدول بالا، می توان دریافت که جنگو و روبی از نظر سرعت مشابه هستند و شما می توانید از هر دو برای ایجاد یک سایت سنگین استفاده کرده و در یک زمان به نتیجه برسید. اما بیایید به دنبال چیزهای مهم تری از سرع باشیم. چیز هایی که قرار است برای موفقیت برنامه ی ما مهم باشند.
با هم دوره ی request در هر فریم ورک را بررسی و ابزار های درگیر در این فرایند را بهتر خواهین شناخت.
برنامه های سنگین سرور های زیادی دارند. Load balancer ابزاری است که مسیر درخواست ها را به سرور مربوطه متصل می کند. در این مرحله یکی از فرمان های مشهور به نام HAProxy.ssl را میتوان اجرا نمود.
این شتاب دهنده ها برای فشرده سازی و ذخیره سازی response ها و ارائه ی سریع آن ها در بین سرور ها و کلاینت ها مورد استفاده قرار می گیرد. یکی از قوی ترین ابزار ها در این زمینه Varnish است.
Nginx احتمالا تمامی کارهای مربوط به فایل های استاتیک و درخواست های پویا را در سرور ها انجام خواهد داد. توجه داشته باشید که Nginx توانایی کار های دو ابزار قبلی ( load balancer , Web accelerator) را دارد، پس پیکر بندی Nginx می تواند کارهای شما را انجام دهد.
سرور وب درخواست های Http را به شی تبدیل می کند تا فریم ورک تحت وب ما بتواند آن ها را اجرا کند. برای مثال، Unicorn برای روبی و Gunicorn برای جنگو.
بیشتر بخوانید:
در نهایت کد هایمان را اجرا خواهیم کرد. برای رسیدن به یک response ،فریم ورک ما باید کارهای زیر را انجام دهد:
درخواست ورود کاربر را بررسی کند و تمامی اطلاعات برای انجام کارهای تمامی صفحه را از پایگاه دادهای گرفته و رندر کند.
در واقعیت، سطوح چندانه cache در برنامه مورد استفاده قرار خواهند گرفت و اگر خالی بودند از پایگاه دادهای استفاده خواهد شد.
برنامه ما سعی می کند تا صفحه ی کاربری را از cache دریافت کند. اگر موجود نبود، بخش های مختلف صفحه را از Cache بیرون خواهد کشید. برای بخش هایی که در cache نیستند، Response ها را از پایگاه داده ای گرفته و رندر خواهد نمود.
تمامی وب سایت ها و برنامه ها بر مبنای پایگاه های داده ای فعالیت می کنند. اگر از پایگاه دادهای انتظار داشته باشیم تا درخواست ها را اجرا کند، زمان زیادی برای پاسخگویی تلف خواهد شد پس انتخاب پایگاه داده مناسب و درخواست های دقیق می تواند در وقت شما صرفه جویی زیادی انجام دهد.
اگر به نظر میرسد که cache خالی نیست، نیازی به اجرای روبی و پایتون نیست. اگر اجرا بشوند فقط برای بخشی از صفحه مورد نیاز هستند. در هنگام اجرا، بخشی از زمان پاسخگویی انتظار برای پایگاه داده ای است. سرعت بالای فریم ورک تاثیری در سرعت کلی ندارد.
وقتی هیچ چیزی در cache نباشد و برنامه باید تمامی درخواست های db را انجام داده و رندر کند، ممکن است کار تا ۲ ثانیه طول بکشد.
زمان پاسخگویی در حالت Cache کامل ۱۰تا ۲۰ میکرو ثانیه است. وقتی بخشی از cache مورد استفاده باشد ۲۰۰میکرو ثانیه است. پس بهینه سازی Cahce ها و ساختارهای پایگاه دادهای می تواند سرعت پاسخگویی را تا ۹۰درصد کاهش دهد.
همانطور که می بینید، تصمیم های معماری داده ها می تواند تغییرات چشمگیری بر سرعت پاسخگویی داشته باشد.
پس می دانیم که روبی و پایتون سهم کمی در سرعت پاسخگویی کلی دارند. حالا بیایید فرق بین روبی و پایتون را در زمان اجرا بسنجیم.
در ژانویه ۲۰۱۷ نتایج بازی اندازه گیری نشان داد که پایتون ۰.۷درصد کند تر از روبی است.
این بازی در لینک زیر قابل دسترسی است:
خوب تا این جای کار می توانید حدس بزنید که تاثیر انتخاب یک فریم ورک کند بر روی عملکرد برنامه ی شما چیست. به هر حال، چیزی که باید در هنگام انتخاب بین روبی و جنگو در نظر داشته باشید سرعت نیست. باید بررسی کنید که یادگیری شما در چه سطحی است و آیا سیستم کاری و تجاری شما با کدام یک از فریم ورک ها هم خوانی دارند.
این فریم ورک ها شباهت های زیادی دارند ولی در فلسفه با یکدیگر فرق می کنند. فقط کافی است یک ماه با آن ها کار کنید و براحتی تشخیص دهید که کدام یک ساده تر است. انتخاب فریم ورک ساده تر کار اشتباهی نیست. اگر شما نتوانید با پایگاه های داده ای و ساختار های فریم ورک ها بخوبی کارکنید عملکرد برنامه ی توسعه یافته توسط شما پایین تر خواهد بود.