| AmirHossein |

🫰🙂‍↔️

احتمالا ورژن 4 لاراگرام تا آخر همین ماه منتشر میشه پروتکل MTProto به صورت کامل پیاده‌سازی شده دقیقا با همون ساختار ساده لاراگرام و بدون درگیر کردن خودمون با جزئیات صرفا با تعریف Listener می‌تونیم یوزربات‌ها رو هم پیاده‌سازی کنیم برای استفاده از MTProto در لاراگرام حتما نیازمند سرورمجازی هستید و امکان استفاده روی هاست‌های اشتراکی نیست(هست ولی async نیست که کاربرد نداره) قابلیت ایمپورت سشن‌ از سایر لایبرری‌های دیگه هم وجود داره سیستم وب روتینگ هم تکمیل شده و صرفا چند پکیج از لاراگرام باقی مونده که توسعه داده بشه و بعد از اون ریلیز لاراگرام به حدی گسترده شده که با ترکیب دو قابلیت Routing و MTProto اون می‌تونید یک کلاینت تلگرام تحت وب ایجاد کنید امیدوارم حمایت بشه ازش

آلما یک اپلیکیشن پایش تغذیه و سلامت هست که توسط چند تا از دوستان توسعه داده شده واقعا پروژه‌شون خفن هست توی این کشور دولت که حامی استارتاپ‌ها نیست حداقل خودمون حمایتشون کنیم❤️

بخند، خیلی پخ خاصی هم هستی آخه

بچه ها به کمک شما نیاز داریم که چنل آلما یکم یوزر بگیره که بتونیم تبلیغات انجام بدیم :) https://t.me/AlmaDiet لطفا توی چنل آلما جوین بشید. ❤️

باید بگم باز خرابش کن ماشین رو

برگشتیم به ۱۰ سال قبل که پول کاغذی استفاده می‌کردیم با این تفاوت که قبلا ۵ ۶ تا ده‌هزاری تو جیبمون می‌ذاشتیم الان یه گونی اسکناس باید حمل کنیم لعنتی یه بانک تو این کشور کار نمی‌کنه رفتم تعمیرگاه طرف ۲ ساعت ماشین رو اوکی کرده پولشو نمی‌تونم بدم

Define the questions. LaraGram Conversation handles the entire user journey — from asking to validating responses.

یک متد HTTP جدید به اسم QUERY معرفی شده که یک سری از مشکلات رو حل میکنه متد QUERY برای ارسال درخواست‌های جستجو یا فیلتر پیچیده به سرور طراحی شده است. از نظر کاربرد شبیه POST است، اما یک تفاوت مهم دارد: - نباید داده‌ای روی سرور تغییر دهد. - اگر چند بار همان درخواست ارسال شود، نتیجه یکسان خواهد بود. معمولاً جستجوها با GET یا POST انجام می‌شوند:

GET /products?category=laptop&brand=dell&price<1000

اما وقتی فیلترها یا شرایط جستجو خیلی بزرگ و پیچیده شوند، قرار دادن همه اطلاعات در URL مشکل‌ساز می‌شود. متد QUERY اجازه می‌دهد اطلاعات جستجو در بدنه (Body) درخواست ارسال شوند.

QUERY /products HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "category": "laptop",
  "brand": "Dell",
  "maxPrice": 1000
}

سرور نتیجه جستجو را برمی‌گرداند، بدون اینکه وضعیت یا داده‌ای را تغییر دهد. متد QUERY در ژوئن ۲۰۲۶ به عنوان RFC 10008 استاندارد شده است، اما هنوز همه وب‌سرورها، فریم‌ورک‌ها و API Gatewayها از آن پشتیبانی نمی‌کنند. بنابراین در بسیاری از APIها هنوز از GET یا POST برای عملیات جستجو استفاده می‌شود. @AmirhDeveloper .

حدود ۵ سال پیش که تصمیم گرفتم پروتکل MTProto رو با PHP ایجاد کنم دانش خیلی خیلی کمی نسبت به الان داشتم توی اون زمان فکر می‌کردم که ساخت یک کلاینت MTProto صرفا به ایجاد یک کانکشن و رمزنگاری‌هاش هست و خب این خودش برام یک کابوس بود چون واقعا پیچیده بود، مخصوصا برای من ۵ سال پیش سال اول حتی جرئت شروع توسعه‌ش رو نداشتم دو سال بعد حدود ۲۰ تلاش ناموفق داشتم(یک فولدر دارم که توش فولدرهایی با اسم MTProto-v1 تا MTProto-v20 هست و هر کدوم یک ورژن کاملا متفاوت و شکست خورده س😁) سال چهارم بالاخره موفق شدم که رمزنگاری‌هاش رو درست انجام بدم و کانکشنم رو برقرار کنم، خوشحال بودم چون همه چیز درست کار می‌کرد سال پنجم که الان هست متوجه شدم که اینها ساده‌ترین بخش کار بودن، و هنوز کلی چیز لازم داره به عنوان مثال، برای اینکه یک پیام bold ارسال کنیم، باید یک انتیتی‌پارسر بنویسیم چون در حالت عادی خود پروتکل یا کلاینت قرار نیست اینهارو بفهمه یک انتیتی‌پارسر که هم مارک‌داون بفهمه، هم html، اونم برای تک تک انتیتی‌های تلگرام متوجه شدم، فایل‌هایی که تلگرام می‌فرسته فایل ساده و معمولی نیستن، و باید فایل دیکودر و انکودر بنویسم، فایل ساده نمیشه ارسال کرد، پس باید فایل آپلودر بنویسم متوجه شدم ریسک‌ بن شدن زیاد هست، باید دیوایس و کلاینت واقعی شبیه‌سازی کنم، ریت‌لیمیتر ایجاد کنم باید بین دیتاسنترها همگام‌سازی ایجاد میکردم خیلی از پارامترهای api تلگرام پیچیده هستن، باید ساده‌سازی می‌کردم خیلی از پارامترهارو پی‌اچ‌پی عزیز async نیست و باید با swoole هندلش می‌کردم باید با لاراگرام سازگارش می‌کردم و احتمالا کلی چیز میز دیگه که در آینده میفهمم و به پشیمونیم اضافه میشه ولی حتی کابوس اصلی این ها هم نیست نگهداری و بروز نگه داشتن اون هست با وجود آپدیت‌های متعدد تلگرام خلاصه که کم کم دارم پشیمون میشم، ولی خیلی دیره واسش😁

لاراگرام ۸ پکیج جدید رو در اختیار توسعه دهنده قرار میده، و این ۸ پکیج لاراگرام رو بی رقیب و از هر چیزی بی‌نیاز میکنن بریم که یکی یکی این هارو معرفی کنیم Laraproto: همونطور که قبلا توضیح داده بودم، لاراگرام توان توسعه user bot هارو خواهد داشت، و این توانایی به لطف Laraproto هست. لاراپروتو یک پیاده سازی کامل از MTProto هست که به شما اجازه ساخت یوزربات هارو میده. تنها محدودیت لاراپروتو این هست که نیازمند پکیج Surge هست تا بتونه به صورت non-block کار بکنه، و این یعنی استفاده از اون تنها روی سرورها ممکن هست، و مناسب هاست‌های اشتراکی نیست! Luna: لونا برای توسعه TMAها، با React.js یا Vue.js هست. شامل دو پکیج هست، یکی برای بک-اند و یکی برای‌فرانت-اند. لونا یک رپر از Inertia برای لاراگرام هست، و به سادگی می‌تونید فرانت خودتون رو توسعه بدید و بدون درگیر شدن با API و... اون رو به بک‌اند رباتتون وصل کنید. Citadel: سیتادل وظیفه مدیریت JWT و احرازهویت APIهارو بر عهده داره، و این مناسب زمانی هست که می‌خواید TMA توسعه بدید، یا یک API برای رباتتون داشته باشید. Sentinel: به لطف HTTP Kernel و Router که جدیدا به لاراگرام اضافه شدن، شما عملا می‌تونید یک وب‌سایت با لاراگرام بسازید. سنتینل یک پنل مانیتورینگ تحت وب هست، کاربران، کش‌ها‌، تسک‌ها، کوئری‌ها و هرچیزی که سمت ربات شما اتفاق میوفته رو مانیتور می‌کنه. Seeker: سیکر برای کار با ElasticSearch هست، و خیلی ساده مدل‌های الوکوئنت شمارو برای الاستیک‌سرچ آماده می‌کنه Armada: آرمادا هم مسئول داکرایز کردن پروژه لاراگرامی شما هست. Brain: برین برای علاقه‌مندان به وایب‌کدینگ هست، برای AI Agentها Tools و Skills فراهم می‌کنه تا کنترل و فهم بیشتری نسبت به پروژه شما داشته باشن. یک MCP Server برای خوندن لاگ‌ها‌ بررسی کوئری‌ها و ساختار دیتابیس، سرچ در داکیومنت لاراگرام و... AI: این پکیج یک SDK برای کار با مدل‌های هوش مصنوعی هست، خیلی ساده می‌تونید به یک مدل هوش‌مصنوعی مثل جمینای یا جی‌پی‌تی یا ... وصل بشید و با متدهای ساده، گفت و گو، تصویر و صدا و.. ایجاد کنید و در نهایت به پکیج Surge که یک سوپرشارژر برای LaraGram هست درایورهای FrankenPHP و RoudRunner اضافه خواهد شد مجدد خوشحال میشم به ریپوزیتوری پروژه استار بدید😁❤️ https://github.com/laraXgram/LaraGram

ورژن 4 فریم‌ورک LaraGram قرار بوداین ماه منتشر بشه، ولی خب بخاطر اتفاقات توسعه‌ش عقب افتاد، و احتمالا توی یکی دو ماه آینده منتشر میشه خیلی واسش هیجان دارم و خب می‌خوام یک توضیحاتی بدم که قراره چی داشته باشیم این ورژن بزرگترین آپدیت رو دریافت می‌کنه، و قرار نیست دیگه چنین آپدیتی داشته باشیم، بعد از منتشر شدن ورژن 4 به جرئت هیچ لایبرری یا فریم‌ورکی توی کامیونیتی تلگرام نیست که با LaraGram رقابت کنه.😁 در ادامه با این تغییرات آشنا میشیم اولین فیچری که می‌خوام بهش اشاره کنم، Router و HTTP Kernel هست. لاراگرام عملا توان توسعه صفحات وب و REST API رو خواهد داشت. این سیستم شامل روتر قدرمند مشابه لاراول، میدلورها، کنترلرها، و هر چیز دیگه برای توسعه صفحات و APIها هست میشه. با این سیستم می‌تونیم TMAها و APIهای خارجی، مثلا برای درگاه پرداخت، یا پنل‌های مدیریتی رو هندل کنیم. در ادامه لاراگرام به سیستم کانورسیشن مجهز میشه این یعنی دیگه لازم نیست درگیر ارسال سوال، مدیریت استپ‌ها، و دریافت پاسخ کاربر بشیم، کافیه سوالاتتون رو به لاراگرام بدید، و وظیفه مدیریت استپ‌ها و پرسش سوالات از کاربر و دریافت پاسخ و اعتبارسنجیش رو به عهده لاراگرام بذارید. فیچر بعدی آنتی‌فلود هوشمند هست، که به طور هوشمند و خودکار بدون هندل دستی حواسش به ربات شما هست که به محدودیت های فلود بر نخوره به لطف این سیستم آنتی فلود، سیستم برادکست فیچر بعدی لاراگرام هست، دیگه لزومی به پیاده‌سازی سرویس پیام همگانی ندارید، فقط متن پیام رو به لاراگرام بدید تا به کاربر هاتون ارسال کنه، نیازی به هیچ گونه اسلیپ یا دیلی بین ارسال‌ها نیست و خود لاراگرام درصورت نیاز این کار رو می‌کنه. قابلیت بعدی سیستم Acting هست، و با اون می‌تونید خودتون رو جای یک کاربر دیگه بذارید، به طوری که انگار دارید با هویت یک شخص دیگه به ربات پیام میدید. مورد بعدی پروکسی هست، که می‌تونیم خیلی ساده یک پروکسی برای ربات ست کنیم. قابلیت FTP، SFTP و... به Filesystem اضافه میشه، و می‌تونید فایل‌های خارج از سرور رو هم مدیریت کنید. و در نهایت قابلیت تعریف لیسنر با اتریبیوت‌های PHP به سیستم آپدیت لیسنر اضافه شده، گه تعریف آپدیت لیسنرها رو به شدت ساده میکمه، و یک کد مرتب و تمیز خواهیم داشت قابلیت‌هایی مثل استریم‌رپرها و JsonSchma هم اضافه شده، که کمتر برای استفاده مستقیم هستن و در ادامه توضیح داده میشن. این موارد صرفا مواردی بودن که مستقیما به هسته لاراگرام اضافه شدن، و فقط چند درصد از آپدیت انقلابی لاراگرام هستن سایر فیچرها تحت پکیج‌های جداگانه اضافه میشن که توی پیام بعدی معرفی میشن. تا اینجا اگر خوشتون اومد، خوشحال میشم به ریپوزیتوری پروژه استار بدید❤️ https://github.com/laraXgram/LaraGram

یکی از مشکلاتی که این آپدیت داشت، این بود که برای نصب حتما نیاز به VPN داشت تا بتونه سایت تلگرام رو اسکرپ کنه ولی توی ورژن جدید با کمک گیت‌هاب اکشنز این اسکرپ روی گیت‌هاب انجام میشه و دیتای مورد نیاز رو از گیت‌هاب می‌گیره. و تا زمانی که گیت‌هاب باز هست نصبش نیازی به VPN نداره همچنین اگر نیازی به متدها و آپدیت‌های تلگرام داشتید می‌تونید از این لینک دریافت کنید: https://raw.githubusercontent.com/laraXgram/telegram-api-data/main/telegram-api.json .

🙂‍↔️

بریم یک توضیح کامل در این مورد با جمع‌بندی نظرات دوستانی که همراهی کردند داشته باشیم. اول از همه مشکلی که اینجا داریم به Cache Stampede (هجوم همزمان درخواست‌ها به دیتابیس بعد از منقضی شدن کش) معروف هست. یعنی تا وقتی کش وجود داره همه چیز خوبه، ولی به محض اینکه TTL تموم بشه، ممکنه ۱۰۰۰ درخواست همزمان Cache Miss بخورن و به جای یک Query، هزار Query به دیتابیس ارسال بشه. این سناریو معمولا زمانی خطرناک‌تر میشه که با یک Hot Key (کلیدی که تعداد بسیار زیادی درخواست به آن ارسال می‌شود) طرف باشیم. خیلی از راهکارها برای کلیدهای معمولی جواب میدن، اما برای Hot Keyها باید بیشتر مراقب بود چون یک اشتباه کوچک می‌تونه فشار زیادی روی دیتابیس ایجاد کنه. اولین راه‌حلی که معمولا به ذهن می‌رسه استفاده از Mutex یا Distributed Lock (قفل سراسری بین چند سرور) هست. یعنی وقتی Cache Miss اتفاق افتاد فقط اولین درخواست اجازه داشته باشه از دیتابیس بخونه و کش رو مجدد پر کنه. بقیه درخواست‌ها یا منتظر بمونن یا چند لحظه بعد دوباره کش رو بررسی کنن. البته Lock به تنهایی مشکل رو کامل حل نمی‌کنه. فشار روی دیتابیس کم میشه اما ممکنه Latency کاربران افزایش پیدا کنه. همچنین در پیاده‌سازی Lock باید به Failure Scenarioها هم فکر کرد. مثلا اگر سرویسی که Lock رو گرفته قبل از آزاد کردنش Crash کنه چه اتفاقی میفته؟ به همین دلیل معمولا Lockها خودشون TTL دارن تا سیستم در وضعیت Deadlock باقی نمونه. برای همین معمولا از Request Coalescing (تجمیع درخواست‌های مشابه) هم استفاده میشه. یعنی اگر ۱۰۰۰ درخواست همزمان برای یک داده وارد بشن، فقط یک درخواست واقعا به دیتابیس بره و بقیه منتظر نتیجه همون درخواست بمونن. اگر تازگی داده خیلی حیاتی نباشه، Stale-While-Revalidate گزینه جذاب‌تریه. در این حالت وقتی TTL تموم میشه، همچنان آخرین مقدار کش به کاربر برگردونده میشه و همزمان یک فرآیند در پس‌زمینه کش رو Refresh می‌کنه. اینطوری کاربر افزایش Latency رو حس نمی‌کنه. راهکار دیگه Cache Warming یا Background Refresh هست. یعنی اصلا منتظر اولین درخواست نمی‌مونیم. قبل از اینکه TTL تموم بشه یک Job در پس‌زمینه کش رو مجدد می‌سازه و جایگزین می‌کنه. در این حالت عملا Cache Miss برای کاربران رخ نمیده. برای کاهش احتمال بروز این مشکل هم میشه از Randomized TTL یا Jitter استفاده کرد. مثلا به جای اینکه همه کلیدها دقیقا ۱۰ دقیقه عمر داشته باشن، بعضی ۹ دقیقه و بعضی ۱۱ دقیقه عمر داشته باشن. این کار باعث میشه تعداد زیادی کلید دقیقا در یک لحظه منقضی نشن. حالا یک سوال مهم اینجاست که اصلا چرا TTL داریم؟ معمولا TTL زمانی استفاده میشه که: - داده ممکنه در دیتابیس تغییر کنه و نمی‌خوایم کش برای همیشه مقدار قدیمی نگه داره. - نمی‌دونیم چه زمانی داده تغییر می‌کنه. - می‌خوایم در نهایت کش خودش به‌روز بشه حتی اگر فراموش کنیم آن را Invalidate کنیم. اما اگر کنترل کامل روی مسیر آپدیت داده داشته باشیم، شاید اصلا نیازی به TTL نباشه. مثلاً میشه از معماری Event-Driven استفاده کرد. یعنی هر زمان داده در دیتابیس تغییر کرد، یک Event منتشر بشه و همون لحظه کش هم آپدیت یا حذف بشه. در این مدل عملا کش همیشه تازه است و دیگر منتظر منقضی شدن TTL نمی‌مونیم. البته این راهکار هم هزینه خودش رو داره. اگر Event از دست بره یا آپدیت کش با خطا مواجه بشه، ممکنه دیتابیس و کش با هم ناسازگار بشن. به همین دلیل خیلی از سیستم‌ها حتی در کنار Event-Driven بودن، یک TTL بلندمدت هم قرار میدن تا اگر جایی مشکلی پیش اومد، کش نهایتا خودش اصلاح بشه. اگر حجم داده خیلی زیاد نباشه میشه یک Hybrid Cache (کش چندلایه) هم داشت. مثلا: - حافظه خود اپلیکیشن به عنوان L1 Cache - و Redis به عنوان L2 Cache در این حالت بسیاری از درخواست‌ها حتی به Redis هم نمی‌رسن و مستقیما از حافظه سرویس پاسخ می‌گیرن. البته در این مدل باید به موضوع Cache Invalidation (هماهنگ نگه داشتن چند کش مختلف) هم فکر کرد. در نهایت انتخاب راهکار تا حد زیادی به Trade-off بین Consistency (تازگی و صحت داده) و Availability (سرعت پاسخگویی و در دسترس بودن سرویس) بستگی داره. اگر داده بسیار حساس باشه شاید ترجیح بدیم درخواست منتظر Refresh شدن کش بمونه، اما اگر تجربه کاربری مهم‌تر باشه معمولا برگردوندن داده‌ای که چند ثانیه یا چند دقیقه از عمرش گذشته قابل قبوله. به همین دلیل معمولا یک راهکار واحد وجود نداره و در سیستم‌های پرترافیک از ترکیبی از همه راهکارها استفاده میشه.

بیاید بیکار نباشیم، هر از گاهی یک سوال چالشی میفرستم که یکم ذهنمون درگیر بشه و یاد بگیریم. از آسون شروع کنیم😁 فرض کنید یک API داریم که داده‌هاش رو از Redis می‌خونه. داده مورد نظر هر ۱۰ دقیقه یک بار Expire میشه و بعد از Expire شدن، اولین درخواست میره دیتابیس رو می‌خونه و مجدد مقدار رو داخل Redis ذخیره می‌کنه. حالا این API حدود ۱۰۰۰ درخواست در ثانیه داره. سوال اینجاست: اگر دقیقاً در لحظه‌ای که Cache Expire شده، ۱۰۰۰ درخواست همزمان به API برسه، چه اتفاقی میفته؟ چه مشکلاتی ممکنه برای Redis، Application و Database ایجاد بشه؟ ایا ۱۰۰۰ درخواست باید به دیتابیس کوئری بزنن؟ شما برای جلوگیری از این مشکل چه راهکارهایی پیشنهاد میدید؟ در پاسخ فقط اسم بردن از راهکارها کافی نیست؛ در مورد نحوه پیاده‌سازی، مزایا، معایب و Trade-off هر راهکار هم توضیح بدید.

خوشبختانه برگشتیم سر کار، و این روزا یکم شلوغ شدم در اولین فرصت که سرم خلوت بشه LaraGram 4 رو تکمیل می‌کنم و ریلیز می‌کنم این ورژن شامل 9 پکیج جدید(تا این لحظه) هست که قراره انقلابی باشه(طبق معمول هیچکس اهمیت نمیده) تا اون موقع لطفا از سیمولا حمایت کنید، به گیت‌هابش استار بدید و به بقیه معرفی کنید خیلی خیلی خوشحالم میشم🤝 https://github.com/laraXgram/Simula .