یادگیری هر زبان یا مهارتی بدون تمرین امکانپذیر نیست یا خیلی سخت امکانپذیر میشه، تمرین کردن به شما کمک میکنه نقاط ضعف خودتون رو شناسایی کنید و بتونید با مطالعه بیشتر و تمرین کدنویسی اون‌هارو پوشش بدید.
اگه نقشه‌راه یادگیری گولنگ رو در سایت مطالعه کرده باشید، حتما متوجه شدید که یکی از بخش‌های مهم یادگیری، انجام پروژه واقعی هست، اینجا قصد دارم سه پروژه کوچک در عین حال واقعی و چالش‌برانگیز رو بهتون معرفی کنم که مطمئن باشید با انجام دادن‌شون کلی مطلب مفید یاد خواهید گرفت. این سه پروژه به تنهایی ممکنه یه بیزینس واقعی رو پوشش نده، اما هر کدومش یه بخش مهمی از خیلی از بیزینس‌های واقعی هستند.
در اینجا قصد دارم ۳ پروژه تمرینی رو معرفی کنم که به شما کمک میکنه گولنگ رو برای توسعه وب بهتر یاد بگیرید.
پروژه شماره ۱: سرویس کوتاه کننده لینک
این سرویس به یه مدل ذخیره‌سازی خیلی ساده احتیاج داره به همراه یه الگوریتم ساده ولی قابل اتکا برای نحوه کوتاه کردن لینک‌ها به شکلی که بتونیم با استفاده از تعداد محدودی کاراکتر، تعداد بسیار زیادی لینک منحصر به فرد رو پوشش بدیم.
تمرین سخت ترش این میشه که به این فکر کنی که برخی از این لینک‌ها تعداد بازدیدشون خیلی خیلی زیاد میشه، مثلا چند میلیون بازدید روزانه، و شما نمیخوای چند میلیون کوئری روی دیتابیس‌ت فقط برای یه لینک بزنی چون خیلی لود زیادی میشه برای دیتابیس، پس به این فکر کن که چه راه‌کاری میتونی به کار بگیری که لود روی دیتابیس رو کم کنی؟ (تقلب: بهتره که از cache استفاده کنی، ببین چه راه‌کار یا راه‌کارهایی برای پیاده‌سازی cache وجود داره، یکی‌ش رو انتخاب کن و پیاده‌سازی کن)
پروژه شماره ۲: سرویس ارسال پیامک
این سرویس به کاربر اجازه میده یه پیام مشخص رو برای یک شماره خاص یا گروهی از شماره‌ها ارسال کنه. وظیفه سرویس اینه که بصورت تضمینی، پیام مورد نظر رو برای همه شماره‌های درخواستی ارسال کنه.
لازم نیست شما خودتون ارسال کننده پیامک باشید، برای ارسال پیامک میتونید از سرویس‌های آماده مثل کاوه‌نگار استفاده کنید. کافیه که شما API مستند شده در سایت کاوه‌نگار رو برای ارسال پیامک پیاده‌سازی کنید و یا از کتابخونه آماده کاوه‌نگار استفاده کنید که لینکش در سایت خودشون هست.
تو این تمرین باید دقت کنی که یه فرض غلطی وجود داره که میگه «network is reliable»، در حالیکه همه ما میدونیم نتورک reliable نیست، پس بهتره که سعی کنی ارسال درخواست‌هارو در مقابل خطاهای گذرای شبکه مقاوم کنی. (تقلب: از retry pattern استفاده کن که اینجا یه مقاله در موردش نوشتم)
سخت‌ترش این میشه که به این فکر کنی که اگه تعداد درخواست‌های همزمان ارسال پیامک زیاد بشه میخوای چیکار کنی؟ مثلا تصور کن که در یک ساعت خاص، مثلا ۸ شب، ۱۰۰ تا کاربر همزمان درخواست ارسال پیامک به ۱ میلیون مخاطب‌شون رو دارند، خب آیا سرویس شما میتونه در یک بازه زمانی کوتاه ۱۰۰ میلیون پیامک رو ارسال کنه؟ برای اینکه زیر این لود وحشتناک سرویسی که نوشتی به فنا نره چه راه‌کاری به ذهنت میرسه؟ (تقلب: بهتره که برای ارسال پیامک صف ایجاد کنی، برای ایجاد صف میتونی از سرویس‌های مختلفی مثل redis، rabbitmq یا nats استفاده کنی)
سخت‌ترترش این میشه که به این فکر کنی که اگه همه درخواست‌هارو داخل یه صف بریزی اونوقت ممکنه همه پیامک‌های یه کاربر زود به دست مخاطبینش برسه اما کاربران دیگه پیامک‌هاشون بره ته صف و خیلی با تاخیر به دست‌شون برسه، برای اینکه تاخیر رو حداقل کنی، یا بهتره بگم تاخیر ارسال پیامک رو برای پیامک‌های همزمان عادلانه کنی چه راه‌کاری به ذهنت میرسه؟ (تقلب: میتونی برای هر پیامک یه صف ایجاد کنی و برای خوندن jobهای هر صف یک worker رو مسئول کنی، یه راه دیگه‌ش هم اینه که صف‌هارو جدا نکنی، اما به کمک topic و subject و تعاریف مختلفی که در brokerها با هم فرق میکنه، consumerهای مختلفی رو ایجاد کنی که هر consumer صرفا پیام‌های یک topic خاص رو میخونه)
پروژه شماره ۳: سرویس آپلود فایل
این سرویس قراره که یه سری فایل رو از کاربر دریافت کنه و اون‌هارو در یک دیسک ذخیره کنه. یکی از چالش‌های این سرویس اینه که فایل‌های آپلود شده هم میتونن به عنوان فایل خصوصی آپلود بشن و هم به عنوان فایل عمومی آپلود بشن. فایلی که به عنوان فایل عمومی آپلود میشه میتونه در اختیار عموم قرار بگیره، پس باید به این فکر کنه که چطور فضای ذخیره‌سازی مجزا برای این دو حالت در نظر بگیری. همچنین باید به این فکر کنی که اگه درخواست دانلود یه سری فایل‌های عمومی زیاد بشه میخوای چیکار کنی؟ (تقلب: فایل رو باید cache کنی یا بهترش این میشه که از cdn استفاده کنی)
تمرین سخت‌ترش این میشه که ذخیره‌سازی فایل رو محدود به یه دیسک لوکال روی سرور نکنی و به کاربر اجازه بدی از بین storageهای مختلف خودش انتخاب کنه فایل کجا ذخیره بشه، مثلا اینکه aws s3 رو انتخاب کنه یا minio رو انتخاب کنه، باید به این فکر کنی که چطور میتونی storageهای مختلف رو تو کد هندل کنی…
تمرین سخت‌ترترش این میشه که برای یه سری فایل‌ها مثل ویدیو و عکس قابلیت فشرده‌سازی رو به کاربر ارائه بدی، با این قابلیت کاربر میتونه درخواست کنه که علاوه بر نسخه اصلی فایل، نسخه کم‌حجم شده فایل هم روی سرور آپلود بشه و فایل کم‌حجم شده به عنوان فایل عمومی در اختیار عموم قرار بگیره، خب حالا تصور کن در یک لحظه خاص ۱۰۰۰ کاربر فایل سنگین‌شون رو آپلود میکنن و شما باید همزمان همه این فایل‌های سنگین رو کم‌حجم کنی، اینم در نظر بگیرید که معمولا پروسه کم‌حجم کردن یه فایل ویدیویی زمان‌بر هست و همچنین منابع سرور مثل cpu و ram رو درگیر میکنه، خب حالا راه حلت چیه؟ (تقلب: باید از یه job scheduler استفاده کنی که jobهای پردازش فایل رو تعریف کنی و یه سری worker داشته باشی که اون‌هارو پردازش کنه، ابزار پیاده‌سازی زیاده، خودتون یکی‌ش رو انتخاب کنید و پیاده‌سازی کنید)