فرض کنید یه پروژه اوپن ‌سورس منتشر کردید و مرتب هم آپدیتش کردید و میخواید بدونید کدوم آپدیت پروژه باعث شده افراد بیشتری بیان و از ریپازیتوری استفاده کنن یا بهش استار بدن. یکی از راهای پر استفاده اینه که یه نمودار از استار هایی که به پروژه داده شده داشته باشید😃

🌟 ابزارایی مثل Star History این نمودار رو طراحی میکنن براتون. اما گرفتن اطلاعات موردنیازشون از API گیت‌هاب، مخصوصا برای ریپو های محبوب تر تا قبل از آپدیت شدن API گیت هاب ساده نبود. مثلا برای ساختن تاریخچه استار های ریپازیتوری React با حدود 251,000 استار به تقریبا 2,511 درخواست نیاز بود! چون API قدیمی اطلاعات رو به شکل صفحه ‌هایی شامل حداکثر 100 کاربر برمیگردوند و ابزارها باید زمان ثبت هر Star رو از اونجا میگرفتن.

این روش علاوه بر تعداد زیاد درخواست ها، دیتابیس رو هم سنگین میکرد. از طرفی، اطلاعات کاربرا در اختیار ابزارایی قرار میگرفت که اصلا به اون نیازی نداشتن. گیت ‌هاب برای حل این مشکل، API جدیدی طراحی کرده که به جای اطلاعات تک‌ تک کاربران، تعداد استار ها رو به تاریخ هر روز برمیگردونه و توی هر درخواست میتونه داده ‌های حداکثر 30 هفته رو ارائه بده.

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

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

📉 نتیجه تست روی ریپازیتوری React که خود گیت هاب توی مقالش بهش اشاره کرده این بوده که برای برگردوندن تاریخچه کامل استارهای ریپازیتوری تعداد درخواستا از 2,511 به 24 رسیده و هر رکورد توی دریافت کل نتیجه، تقریبا یه بار بررسی شده.

💡 نکته ای که این موضوع داره اینه که باید بدونیم کم ‌کردن تعداد نتایج یه کوئری لزوما باعث سریعتر شدن اون نمیشه و مهمه که قبل از اجرای پردازش های سنگین، داده‌های غیر ضروری رو که بهشون نیازی نداریم فیلتر کنیم.

#github #star #news
☕️ Telegram | Website | Discord