متد جدید HTTP؛ آشنایی با QUERY
اگر تا حالا با REST یا HTTP کار کرده باشید، قطعا با متدهای GET، POST، PUT، PATCH و DELETE آشنایی دارید. اما بعد از حدود ۱۶ سال، یک متد جدید به پروتکل HTTP اضافه شده که اسمش QUERY هست.
بیاید با یه مثال ببینیم اصلاً چرا چنین متدی به وجود اومده.
فرض کنید یه endpoint به اسم orders داریم که از Pagination، Filter، Sort و موارد مشابه پشتیبانی میکنه. معمولاً برای دریافت اطلاعات از متد GET استفاده میکنیم و پارامترها رو هم به صورت Query String داخل URL میفرستیم.
این روش سالهاست که استفاده میشه و تو اکثر مواقع هم کاملاً منطقیه، اما چند تا محدودیت داره:
• طول URL محدوده (معمولاً حدود ۸۰۰۰ کاراکتر یا حتی کمتر، بسته به سرور و مرورگر)
• پارامترها داخل URL قرار میگیرن و ممکنه توی لاگهای سرور ثبت بشن.
• ساختن کوئریهای پیچیده مثل فیلترهای پیشرفته، SQL، JSONPath و... سخت یا حتی غیرممکنه.
• انکودینگ کردن پارامترهای پیچیده هم دردسرهای خودش رو داره.
معمولاً وقتی به این محدودیتها میرسیم، خیلیها به جای GET از POST استفاده میکنن و پارامترها رو داخل Body درخواست میذارن.
این روش مشکل محدودیت URL رو حل میکنه، اما خودش چند تا ایراد مهم داره:
• متد POST ذاتاً Idempotent نیست؛ یعنی اگر وسط ارسال درخواست ارتباط قطع بشه، نمیشه با خیال راحت همون درخواست رو دوباره ارسال کرد، چون ممکنه عملیات دوباره انجام بشه.
• پاسخهای POST به صورت پیشفرض از Cache استاندارد HTTP استفاده نمیکنن.
• پروکسی ها و CDNها نمیتونن تشخیص بدن که ارسال مجدد این درخواست امن هست یا نه.
• هر فریمورک هم معمولاً راهکار خودش رو برای پیادهسازی چیزی مثل Safe POST داره و استاندارد یکپارچهای وجود نداره.
اینجاست که QUERY وارد میشه.
ایدهی اصلی QUERY اینه که بهترین ویژگیهای GET و POST رو با هم ترکیب کنه. از یه طرف مثل GET فقط برای خوندن اطلاعات استفاده میشه و هیچ تغییری روی وضعیت سرور ایجاد نمیکنه، و از طرف دیگه مثل POST میتونه دادههای پیچیده رو داخل Body درخواست ارسال کنه.
در نتیجه درخواستهامون به این شکل درمیاد:
به این ترتیب دیگه محدودیت طول URL وجود نداره و میتونید هر نوع فیلتر پیچیده، کوئری، JSONPath یا هر دادهی دیگهای رو داخل Body ارسال کنید.
اما مزیت QUERY فقط این نیست.
یکی از مهمترین ویژگیهای این متد، Idempotent بودنشه. یعنی اگر به هر دلیلی ارتباط شبکه قطع بشه، کلاینت میتونه همون درخواست رو دوباره ارسال کنه و مطمئن باشه نتیجه دقیقاً همون نتیجهی قبلی خواهد بود. برخلاف POST که ارسال مجددش ممکنه باعث ایجاد دادههای تکراری یا اجرای دوبارهی عملیات بشه.
از طرف دیگه، چون QUERY یک متد Safe محسوب میشه و فقط برای دریافت داده استفاده میشه، زیرساختهای HTTP مثل مرورگرها، Proxyها و CDNها میتونن پاسخش رو مثل GET کش کنن. یعنی درخواستهای پیچیدهای که قبلاً مجبور بودیم با POST بفرستیم، حالا میتونن از مزایای Cache استاندارد HTTP هم استفاده کنن.
یکی دیگه از قابلیتهای جالب QUERY اینه که سرور میتونه برای خودِ درخواست یک URI دائمی ایجاد کنه. یعنی به جای اینکه فقط نتیجهی جستجو قابل دسترس باشه، خود Query هم یک آدرس اختصاصی خواهد داشت. هر بار که اون آدرس فراخوانی بشه، همون جستجو دوباره روی دادههای جدید اجرا میشه. این قابلیت برای Share کردن جستجوها، Bookmark کردنشون یا اجرای دورهای یک Query بدون ارسال دوبارهی Body خیلی کاربردیه.
در نهایت، متد QUERY به صورت رسمی استاندارد شده، اما هنوز راه زیادی تا استفادهی گسترده ازش باقی مونده. بعضی از اکوسیستمها مثل Go و Java کار روی پشتیبانی ازش رو شروع کردن و احتمالاً در آینده اسم این متد رو بیشتر خواهیم شنید. البته فعلاً پشتیبانی ازش محدود به چند کتابخونه و سرور خاصه و هنوز اکثر فریمورکها و API Gatewayها ازش پشتیبانی کامل ندارن.
اگر دوست دارید بیشتر درباره این متد بدونید، پیشنهاد میکنم RFC مربوط بهش رو هم بخونید:
https://www.rfc-editor.org/info/rfc10008
#programming
@Syntax_fa
اگر تا حالا با REST یا HTTP کار کرده باشید، قطعا با متدهای GET، POST، PUT، PATCH و DELETE آشنایی دارید. اما بعد از حدود ۱۶ سال، یک متد جدید به پروتکل HTTP اضافه شده که اسمش QUERY هست.
بیاید با یه مثال ببینیم اصلاً چرا چنین متدی به وجود اومده.
فرض کنید یه endpoint به اسم orders داریم که از Pagination، Filter، Sort و موارد مشابه پشتیبانی میکنه. معمولاً برای دریافت اطلاعات از متد GET استفاده میکنیم و پارامترها رو هم به صورت Query String داخل URL میفرستیم.
GET /orders?status=paid&limit=20&offset=0
این روش سالهاست که استفاده میشه و تو اکثر مواقع هم کاملاً منطقیه، اما چند تا محدودیت داره:
• طول URL محدوده (معمولاً حدود ۸۰۰۰ کاراکتر یا حتی کمتر، بسته به سرور و مرورگر)
• پارامترها داخل URL قرار میگیرن و ممکنه توی لاگهای سرور ثبت بشن.
• ساختن کوئریهای پیچیده مثل فیلترهای پیشرفته، SQL، JSONPath و... سخت یا حتی غیرممکنه.
• انکودینگ کردن پارامترهای پیچیده هم دردسرهای خودش رو داره.
معمولاً وقتی به این محدودیتها میرسیم، خیلیها به جای GET از POST استفاده میکنن و پارامترها رو داخل Body درخواست میذارن.
POST /orders HTTP/1.1
Host: api.example.org
Content-Type: application/x-www-form-urlencoded
select=surname,givenname,email&limit=10&match="email=@example."
این روش مشکل محدودیت URL رو حل میکنه، اما خودش چند تا ایراد مهم داره:
• متد POST ذاتاً Idempotent نیست؛ یعنی اگر وسط ارسال درخواست ارتباط قطع بشه، نمیشه با خیال راحت همون درخواست رو دوباره ارسال کرد، چون ممکنه عملیات دوباره انجام بشه.
• پاسخهای POST به صورت پیشفرض از Cache استاندارد HTTP استفاده نمیکنن.
• پروکسی ها و CDNها نمیتونن تشخیص بدن که ارسال مجدد این درخواست امن هست یا نه.
• هر فریمورک هم معمولاً راهکار خودش رو برای پیادهسازی چیزی مثل Safe POST داره و استاندارد یکپارچهای وجود نداره.
اینجاست که QUERY وارد میشه.
ایدهی اصلی QUERY اینه که بهترین ویژگیهای GET و POST رو با هم ترکیب کنه. از یه طرف مثل GET فقط برای خوندن اطلاعات استفاده میشه و هیچ تغییری روی وضعیت سرور ایجاد نمیکنه، و از طرف دیگه مثل POST میتونه دادههای پیچیده رو داخل Body درخواست ارسال کنه.
در نتیجه درخواستهامون به این شکل درمیاد:
QUERY /orders HTTP/1.1
Host: api.example.org
Content-Type: application/x-www-form-urlencoded
Accept: application/json
select=surname,givenname,email&limit=10&match="email=@example."
به این ترتیب دیگه محدودیت طول URL وجود نداره و میتونید هر نوع فیلتر پیچیده، کوئری، JSONPath یا هر دادهی دیگهای رو داخل Body ارسال کنید.
اما مزیت QUERY فقط این نیست.
یکی از مهمترین ویژگیهای این متد، Idempotent بودنشه. یعنی اگر به هر دلیلی ارتباط شبکه قطع بشه، کلاینت میتونه همون درخواست رو دوباره ارسال کنه و مطمئن باشه نتیجه دقیقاً همون نتیجهی قبلی خواهد بود. برخلاف POST که ارسال مجددش ممکنه باعث ایجاد دادههای تکراری یا اجرای دوبارهی عملیات بشه.
از طرف دیگه، چون QUERY یک متد Safe محسوب میشه و فقط برای دریافت داده استفاده میشه، زیرساختهای HTTP مثل مرورگرها، Proxyها و CDNها میتونن پاسخش رو مثل GET کش کنن. یعنی درخواستهای پیچیدهای که قبلاً مجبور بودیم با POST بفرستیم، حالا میتونن از مزایای Cache استاندارد HTTP هم استفاده کنن.
یکی دیگه از قابلیتهای جالب QUERY اینه که سرور میتونه برای خودِ درخواست یک URI دائمی ایجاد کنه. یعنی به جای اینکه فقط نتیجهی جستجو قابل دسترس باشه، خود Query هم یک آدرس اختصاصی خواهد داشت. هر بار که اون آدرس فراخوانی بشه، همون جستجو دوباره روی دادههای جدید اجرا میشه. این قابلیت برای Share کردن جستجوها، Bookmark کردنشون یا اجرای دورهای یک Query بدون ارسال دوبارهی Body خیلی کاربردیه.
در نهایت، متد QUERY به صورت رسمی استاندارد شده، اما هنوز راه زیادی تا استفادهی گسترده ازش باقی مونده. بعضی از اکوسیستمها مثل Go و Java کار روی پشتیبانی ازش رو شروع کردن و احتمالاً در آینده اسم این متد رو بیشتر خواهیم شنید. البته فعلاً پشتیبانی ازش محدود به چند کتابخونه و سرور خاصه و هنوز اکثر فریمورکها و API Gatewayها ازش پشتیبانی کامل ندارن.
اگر دوست دارید بیشتر درباره این متد بدونید، پیشنهاد میکنم RFC مربوط بهش رو هم بخونید:
https://www.rfc-editor.org/info/rfc10008
#programming
@Syntax_fa
www.rfc-editor.org
RFC 10008: The HTTP QUERY Method | RFC Editor
This specification defines the QUERY method for HTTP. A QUERY requests that the request target process the enclosed content in a safe and idempotent manner and then respond with the result of that processing. This is similar to POST requests, but QUERY requests…
🔥20❤2👍2
مفهوم Idempotent یعنی چیه؟ چرا این مفهوم همه جا دیده میشه؟
اگه یه مدتی برنامهنویسی کرده باشید، احتمالاً اسم Idempotent به گوشتون خورده. ممکنه این اصطلاح رو توی APIها، پایگاه داده، سیستمهای توزیعشده، صفهای پیام یا حتی ابزارهای DevOps دیده باشید. اما واقعاً Idempotent یعنی چی؟
بیاید با یه مثال ساده شروع کنیم.
فرض کنید یه کلید برق داریم که فقط وظیفهش روشن کردن چراغه. اگه چراغ خاموش باشه و کلید رو بزنید، چراغ روشن میشه. حالا اگه دوباره همون کلید رو بزنید چی میشه؟ هیچ اتفاق جدیدی نمیافته؛ چراغ همچنان روشنه.
مهم نیست این کار رو یک بار انجام بدید یا ده بار؛ نتیجهی نهایی همیشه یکیه. دقیقاً به چنین رفتاری میگن Idempotent.
حالا یه مثال برعکس.
فرض کنید دکمهای داریم که هر بار فشار دادنش، ۱۰۰ هزار تومان به موجودی کیف پول اضافه میکنه. بار اول موجودی ۱۰۰ هزار تومان زیاد میشه، بار دوم دوباره ۱۰۰ هزار تومان اضافه میشه و بار سوم هم همین اتفاق تکرار میشه.
اینجا هر بار اجرای عملیات، وضعیت سیستم رو تغییر میده. پس این عملیات Idempotent نیست.
تعریف رسمی Idempotent هم تقریباً همینه؛ اگه یه عملیات رو یک بار اجرا کنیم یا چند بار پشت سر هم، وضعیت نهایی سیستم باید یکسان باشه.
یه نکتهی مهم اینجاست که Idempotent بودن به این معنی نیست که خروجی عملیات همیشه یکی باشه. ممکنه هر بار اطلاعات متفاوتی برگرده، زمان اجرا فرق کنه یا حتی پیام متفاوتی نمایش داده بشه. چیزی که مهمه اینه که اجرای دوبارهی همون عملیات، وضعیت سیستم رو بیشتر از دفعهی اول تغییر نده.
یکی از اشتباههای رایج اینه که Idempotent رو با عملیاتی که هیچ تغییری ایجاد نمیکنه، اشتباه میگیرن. در حالی که یه عملیات Idempotent میتونه وضعیت سیستم رو تغییر بده؛ فقط این تغییر باید فقط بار اول اتفاق بیفته.
مثلاً اگه عملیاتی وضعیت یه کاربر رو از «غیرفعال» به «فعال» تغییر بده، بار اول وضعیت عوض میشه، اما اگه دوباره همون عملیات اجرا بشه، دیگه تغییری ایجاد نمیکنه.
پس این عملیات همچنان Idempotent محسوب میشه.
از اون طرف، عملیاتهایی مثل «افزایش موجودی»، «افزایش تعداد بازدید»، «ارسال ایمیل» یا «ثبت سفارش جدید» معمولاً Idempotent نیستن؛ چون هر بار اجرا شدنشون یه اثر جدید روی سیستم میذاره.
دلیل اهمیت Idempotent فقط سادهتر شدن منطق برنامه نیست.
توی سیستمهای واقعی همیشه ممکنه شبکه قطع بشه، درخواست Timeout بشه، کلاینت دوباره درخواست رو Retry کنه یا یه Job دوباره اجرا بشه.
اگه عملیات شما Idempotent باشه، دیگه مهم نیست همون عملیات چند بار اجرا بشه؛ نتیجهی نهایی تغییری نمیکنه و سیستم توی وضعیت درستی باقی میمونه.
به خاطر همین، این مفهوم تقریباً توی همهی شاخههای مهندسی نرمافزار دیده میشه؛ از طراحی APIها گرفته تا پایگاه داده، Message Queueها، Event-Driven Architecture، Infrastructure و حتی ابزارهای مدیریت سرور.
در نهایت، Idempotent یه تکنولوژی یا قابلیت خاص نیست؛ یه ویژگی برای طراحی عملیاته.
هر وقت بتونید عملیاتی طراحی کنید که اجرای دوبارهی اون، وضعیت نهایی سیستم رو تغییر نده، اون عملیات Idempotent محسوب میشه.
#programming #software_engineering
@Syntax_fa
اگه یه مدتی برنامهنویسی کرده باشید، احتمالاً اسم Idempotent به گوشتون خورده. ممکنه این اصطلاح رو توی APIها، پایگاه داده، سیستمهای توزیعشده، صفهای پیام یا حتی ابزارهای DevOps دیده باشید. اما واقعاً Idempotent یعنی چی؟
بیاید با یه مثال ساده شروع کنیم.
فرض کنید یه کلید برق داریم که فقط وظیفهش روشن کردن چراغه. اگه چراغ خاموش باشه و کلید رو بزنید، چراغ روشن میشه. حالا اگه دوباره همون کلید رو بزنید چی میشه؟ هیچ اتفاق جدیدی نمیافته؛ چراغ همچنان روشنه.
مهم نیست این کار رو یک بار انجام بدید یا ده بار؛ نتیجهی نهایی همیشه یکیه. دقیقاً به چنین رفتاری میگن Idempotent.
حالا یه مثال برعکس.
فرض کنید دکمهای داریم که هر بار فشار دادنش، ۱۰۰ هزار تومان به موجودی کیف پول اضافه میکنه. بار اول موجودی ۱۰۰ هزار تومان زیاد میشه، بار دوم دوباره ۱۰۰ هزار تومان اضافه میشه و بار سوم هم همین اتفاق تکرار میشه.
اینجا هر بار اجرای عملیات، وضعیت سیستم رو تغییر میده. پس این عملیات Idempotent نیست.
تعریف رسمی Idempotent هم تقریباً همینه؛ اگه یه عملیات رو یک بار اجرا کنیم یا چند بار پشت سر هم، وضعیت نهایی سیستم باید یکسان باشه.
یه نکتهی مهم اینجاست که Idempotent بودن به این معنی نیست که خروجی عملیات همیشه یکی باشه. ممکنه هر بار اطلاعات متفاوتی برگرده، زمان اجرا فرق کنه یا حتی پیام متفاوتی نمایش داده بشه. چیزی که مهمه اینه که اجرای دوبارهی همون عملیات، وضعیت سیستم رو بیشتر از دفعهی اول تغییر نده.
یکی از اشتباههای رایج اینه که Idempotent رو با عملیاتی که هیچ تغییری ایجاد نمیکنه، اشتباه میگیرن. در حالی که یه عملیات Idempotent میتونه وضعیت سیستم رو تغییر بده؛ فقط این تغییر باید فقط بار اول اتفاق بیفته.
مثلاً اگه عملیاتی وضعیت یه کاربر رو از «غیرفعال» به «فعال» تغییر بده، بار اول وضعیت عوض میشه، اما اگه دوباره همون عملیات اجرا بشه، دیگه تغییری ایجاد نمیکنه.
پس این عملیات همچنان Idempotent محسوب میشه.
از اون طرف، عملیاتهایی مثل «افزایش موجودی»، «افزایش تعداد بازدید»، «ارسال ایمیل» یا «ثبت سفارش جدید» معمولاً Idempotent نیستن؛ چون هر بار اجرا شدنشون یه اثر جدید روی سیستم میذاره.
دلیل اهمیت Idempotent فقط سادهتر شدن منطق برنامه نیست.
توی سیستمهای واقعی همیشه ممکنه شبکه قطع بشه، درخواست Timeout بشه، کلاینت دوباره درخواست رو Retry کنه یا یه Job دوباره اجرا بشه.
اگه عملیات شما Idempotent باشه، دیگه مهم نیست همون عملیات چند بار اجرا بشه؛ نتیجهی نهایی تغییری نمیکنه و سیستم توی وضعیت درستی باقی میمونه.
به خاطر همین، این مفهوم تقریباً توی همهی شاخههای مهندسی نرمافزار دیده میشه؛ از طراحی APIها گرفته تا پایگاه داده، Message Queueها، Event-Driven Architecture، Infrastructure و حتی ابزارهای مدیریت سرور.
در نهایت، Idempotent یه تکنولوژی یا قابلیت خاص نیست؛ یه ویژگی برای طراحی عملیاته.
هر وقت بتونید عملیاتی طراحی کنید که اجرای دوبارهی اون، وضعیت نهایی سیستم رو تغییر نده، اون عملیات Idempotent محسوب میشه.
#programming #software_engineering
@Syntax_fa
👍19👀1
معرفی ربات controller bot
این ربات برای کسایی که کانال دارن بدرد میخوره
میتونید باهاش پست هایی با دکمه های شیشه ای بذارید
تو پستتون عکس بذارید و این حرفا.
شبیه به این پستمون:
https://t.me/Zervana/98
@Syntax_fa
این ربات برای کسایی که کانال دارن بدرد میخوره
میتونید باهاش پست هایی با دکمه های شیشه ای بذارید
تو پستتون عکس بذارید و این حرفا.
شبیه به این پستمون:
https://t.me/Zervana/98
@Syntax_fa
🔥5👍1
تفاوت مدل های پردازش داده OLTP و OLAP
وقتی یه سیستم بزرگ طراحی میکنید، خیلی زود متوجه میشید که همهی بارهای کاری شبیه هم نیستن. بعضی درخواستها فقط میخوان یه رکورد رو ثبت یا ویرایش کنن، ولی بعضی دیگه باید میلیونها رکورد رو بررسی کنن تا یه گزارش یا تحلیل تولید بشه.
به همین خاطر، پایگاههای داده معمولاً برای یکی از دو مدل OLTP یا OLAP بهینه میشن.
🔹سیستم OLTP (Online Transaction Processing)
سیستمهای OLTP برای انجام تراکنشهای روزمره ساخته شدن. هر درخواست معمولاً کوتاهه، روی تعداد کمی از رکوردها کار میکنه و باید توی کمترین زمان ممکن جواب بده.
تمرکز اصلی OLTP روی سرعت، همزمانی و حفظ یکپارچگی دادههاست. به همین دلیل معمولاً از دیتابیسهای نرمالسازیشده استفاده میکنه تا عملیات ثبت، ویرایش و حذف دادهها سریع و مطمئن انجام بشن.
چند نمونه از بارهای کاری OLTP:
• ثبت سفارش توی فروشگاه آنلاین
• انتقال وجه در سیستم بانکی
• تغییر موجودی کالا
• ورود یا ثبتنام کاربران
🔹 سیستم OLAP (Online Analytical Processing)
برخلاف OLTP، OLAP برای تحلیل دادهها ساخته شده، نه انجام تراکنشهای روزمره.
اینجا معمولاً با کوئریهایی طرف هستیم که حجم زیادی از داده رو میخونن تا به یه نتیجه برسن؛ مثلاً محاسبه فروش یک سال گذشته، تحلیل رفتار کاربران یا ساخت داشبوردهای مدیریتی.
توی OLAP، سرعت انجام یک تراکنش مهم نیست؛ چیزی که اهمیت داره اینه که سیستم بتونه کوئریهای سنگین رو روی حجم زیادی از داده با کارایی مناسب اجرا کنه. به همین خاطر، دادهها معمولاً داخل Data Warehouse نگهداری میشن و ساختارشون برای تحلیل بهینه شده.
چند نمونه از بارهای کاری OLAP:
• گزارش فروش ماهانه یا سالانه
• تحلیل رفتار کاربران
• داشبوردهای مدیریتی
• گزارشهای هوش تجاری (BI)
🔹 تفاوت OLTP و OLAP
با اینکه هر دو با داده سروکار دارن، ولی هدفشون کاملاً متفاوته. OLTP برای اجرای تعداد زیادی تراکنش کوچیک و سریع طراحی شده؛ یعنی هر درخواست فقط چند رکورد رو میخونه یا تغییر میده و تأخیر پایین براش خیلی مهمه.
از اون طرف، OLAP برای اجرای کوئریهای تحلیلی ساخته شده؛ کوئریهایی که ممکنه میلیونها رکورد رو اسکن کنن تا یه گزارش یا تحلیل تولید بشه.
به همین دلیل، توی خیلی از معماریهای مدرن این دو از هم جدا هستن. سیستم عملیاتی (OLTP) فقط مسئول اجرای تراکنشهاست و دادهها بهصورت دورهای به یک Data Warehouse منتقل میشن تا تحلیلها روی اون انجام بشه. این جداسازی باعث میشه هم سیستم عملیاتی سریع باقی بمونه و هم گزارشهای تحلیلی، بدون فشار آوردن به دیتابیس اصلی، اجرا بشن.
#system_design #software_engineering #backend
@Syntax_fa
وقتی یه سیستم بزرگ طراحی میکنید، خیلی زود متوجه میشید که همهی بارهای کاری شبیه هم نیستن. بعضی درخواستها فقط میخوان یه رکورد رو ثبت یا ویرایش کنن، ولی بعضی دیگه باید میلیونها رکورد رو بررسی کنن تا یه گزارش یا تحلیل تولید بشه.
به همین خاطر، پایگاههای داده معمولاً برای یکی از دو مدل OLTP یا OLAP بهینه میشن.
🔹سیستم OLTP (Online Transaction Processing)
سیستمهای OLTP برای انجام تراکنشهای روزمره ساخته شدن. هر درخواست معمولاً کوتاهه، روی تعداد کمی از رکوردها کار میکنه و باید توی کمترین زمان ممکن جواب بده.
تمرکز اصلی OLTP روی سرعت، همزمانی و حفظ یکپارچگی دادههاست. به همین دلیل معمولاً از دیتابیسهای نرمالسازیشده استفاده میکنه تا عملیات ثبت، ویرایش و حذف دادهها سریع و مطمئن انجام بشن.
چند نمونه از بارهای کاری OLTP:
• ثبت سفارش توی فروشگاه آنلاین
• انتقال وجه در سیستم بانکی
• تغییر موجودی کالا
• ورود یا ثبتنام کاربران
🔹 سیستم OLAP (Online Analytical Processing)
برخلاف OLTP، OLAP برای تحلیل دادهها ساخته شده، نه انجام تراکنشهای روزمره.
اینجا معمولاً با کوئریهایی طرف هستیم که حجم زیادی از داده رو میخونن تا به یه نتیجه برسن؛ مثلاً محاسبه فروش یک سال گذشته، تحلیل رفتار کاربران یا ساخت داشبوردهای مدیریتی.
توی OLAP، سرعت انجام یک تراکنش مهم نیست؛ چیزی که اهمیت داره اینه که سیستم بتونه کوئریهای سنگین رو روی حجم زیادی از داده با کارایی مناسب اجرا کنه. به همین خاطر، دادهها معمولاً داخل Data Warehouse نگهداری میشن و ساختارشون برای تحلیل بهینه شده.
چند نمونه از بارهای کاری OLAP:
• گزارش فروش ماهانه یا سالانه
• تحلیل رفتار کاربران
• داشبوردهای مدیریتی
• گزارشهای هوش تجاری (BI)
🔹 تفاوت OLTP و OLAP
با اینکه هر دو با داده سروکار دارن، ولی هدفشون کاملاً متفاوته. OLTP برای اجرای تعداد زیادی تراکنش کوچیک و سریع طراحی شده؛ یعنی هر درخواست فقط چند رکورد رو میخونه یا تغییر میده و تأخیر پایین براش خیلی مهمه.
از اون طرف، OLAP برای اجرای کوئریهای تحلیلی ساخته شده؛ کوئریهایی که ممکنه میلیونها رکورد رو اسکن کنن تا یه گزارش یا تحلیل تولید بشه.
به همین دلیل، توی خیلی از معماریهای مدرن این دو از هم جدا هستن. سیستم عملیاتی (OLTP) فقط مسئول اجرای تراکنشهاست و دادهها بهصورت دورهای به یک Data Warehouse منتقل میشن تا تحلیلها روی اون انجام بشه. این جداسازی باعث میشه هم سیستم عملیاتی سریع باقی بمونه و هم گزارشهای تحلیلی، بدون فشار آوردن به دیتابیس اصلی، اجرا بشن.
#system_design #software_engineering #backend
@Syntax_fa
🔥5👍2
بازنویسی Bun از Zig به Rust؛ کاملاً با هوش مصنوعی
همونطور که احتمالاً میدونید، Bun یک JavaScript Runtime مدرنه که با تمرکز روی سرعت ساخته شده. این پروژه در ابتدا با Zig توسعه پیدا کرد؛ چون Zig به یک تیم کوچک اجازه میداد بدون سربار Garbage Collector و Runtimeهای سنگین، خیلی سریع یک Runtime پرسرعت بسازه. دسترسی مستقیم به حافظه، سادگی زبان و تعامل خوب با C باعث شد معماری و طراحی سطح پایین Bun حول Zig شکل بگیره؛ موضوعی که Jarred Sumner، خالق Bun، هم بارها بهش اشاره کرده.
اما در ماه می امسال، تیم Bun اعلام کرد که قصد داره کل پروژه رو به Rust مهاجرت بده. حالا این بازنویسی انجام شده و کدهای Rust هم وارد شاخه اصلی پروژه شدن. نکتهی عجیب اینجاست که تقریباً تمام این کدها توسط Claude Code تولید شدن و علاوه بر بازنویسی، تعدادی از باگهای قدیمی هم در همین فرآیند برطرف شدن.
آیا مشکل از Zig بود؟
از نگاه تیم Bun، مشکل اصلی خود Zig نبود؛ بلکه مدیریت دستی حافظه در کنار Garbage Collector جاوااسکریپت بود. این ترکیب باعث نشت حافظه، کرش و هزینهی بالای نگهداری کد میشد و با بزرگتر شدن پروژه، اتکا به دقت برنامهنویس دیگر کافی نبود.
با این حال، جرد تأکید میکنه که Zig نقش مهمی در موفقیت اولیه Bun داشته و بخش بزرگی از معماری و عملکرد فعلی پروژه مدیون همون انتخاب اولیه است.
در مقابل، اندرو کلی، خالق Zig، بارها گفته مشکل از زبان Zig نبوده، بلکه از نحوهی استفادهی Bun از اون بوده. حتی جایی گفته بود داخل تیم Zig، از Bun بهعنوان مثالی استفاده میکنیم که «چطور نباید با Zig برنامه نوشت».
چرا Rust؟
بخش بزرگی از باگهای Bun به مدیریت حافظه مربوط میشد. در Rust این دسته از خطاها معمولاً هنگام کامپایل شناسایی میشن و مکانیزم Ownership و Drop هم آزادسازی حافظه رو مدیریت میکنن. در نتیجه، به جای اینکه توسعهدهنده همیشه مراقب همهچیز باشه، کامپایلر جلوی بخش زیادی از اشتباهات رو میگیره.
البته بازنویسی پروژهای با بیش از ۵۳۵ هزار خط کد Zig اصلاً تصمیم سادهای نبود. انجام دستی این کار حداقل یک سال زمان میبرد و عملاً توسعهی Bun رو متوقف میکرد. تیم ابتدا سعی کرد با Smart Pointerهای الهامگرفته از Rust و سختگیرتر کردن قوانین کدنویسی، مشکلات رو داخل Zig حل کنه، اما در نهایت تصمیم گرفت از Claude Code برای بازنویسی کامل پروژه استفاده کنه.
کلاد چطور این بازنویسی را انجام داد؟
جرد میگه ماجرا به سادگی این نبود که به Claude بگه «کل Bun رو به Rust تبدیل کن». قبل از شروع، ساعتها صرف طراحی Workflowها و استراتژی بازنویسی شد.
در نهایت، حدود ۵۰ Workflow مختلف به مدت ۱۱ روز تقریباً بدون توقف اجرا شدن؛ با هزینهای نزدیک به ۱۶۵ هزار دلار.
هر Workflow وظیفهی مشخصی داشت؛ از تبدیل الگوهای Zig به Rust و رفع خطاهای کامپایل گرفته تا اجرای
جرد هم بهجای اصلاح مستقیم خروجیها، Workflowها و Promptها رو بهبود میداد تا هر بار کیفیت خروجی بهتر بشه.
برای اعتماد به بیش از یک میلیون خط کد تولیدشده توسط هوش مصنوعی هم از روشی شبیه Code Review واقعی استفاده شد. یک Claude کد رو مینوشت و چند Claude دیگه، در Contextهای جداگانه، فقط وظیفه داشتن ایرادها و باگها رو پیدا کنن. نویسندهی کد Reviewer نبود و Reviewer هم اجازهی تغییر کد رو نداشت.
بعد از تبدیل همهی فایلها، مرحلهی اصلی یعنی رفع خطاها و پاس کردن تستها شروع شد. این چرخه بارها تکرار شد تا در نهایت تمام تستهای Bun روی همهی پلتفرمها با موفقیت پاس شدن و کد وارد شاخهی اصلی پروژه شد.
آیا این بازنویسی موفق خواهد بود؟
در کوتاهمدت احتمالاً بله. تستها مسیرهای اصلی رو پوشش میدن، نسخههای Canary مشکلات واضح رو پیدا میکنن و Rust هم بخش بزرگی از خطاهای مدیریت حافظه رو حذف میکنه.
اما سؤال اصلی بلندمدته.
اگر چند ماه بعد یک باگ پیچیدهی Concurrency یا یک حالت مرزی عجیب ظاهر بشه، مهندسی که مسئول دیباگ کردنشه با کدی روبهرو میشه که تقریباً هیچ انسانی اون رو بهطور کامل ننوشته یا خطبهخط درکش نکرده.
در نهایت، شرطبندی اصلی این پروژه نه روی Zig و Rust، بلکه روی این سؤاله که آیا یک Codebase عظیم که عمدتاً توسط هوش مصنوعی تولید شده، در بلندمدت هم قابل نگهداری و قابل اعتماد خواهد بود یا نه.
از طرف دیگه، بعضیها هم معتقدن این اتفاق فقط یک بازنویسی فنی نبوده و بخشی از یک کمپین بازاریابی برای Claude محسوب میشه.
پاسخ اینکه این تصمیم در نهایت موفق خواهد بود یا نه، فعلاً مشخص نیست؛ چیزی که فقط با گذر زمان معلوم میشه.
مقاله ای که خود جرد منتشر کرده و در مورد این تغییرات توضیح داده:
https://bun.com/blog/bun-in-rust
#News
@Syntax_fa
همونطور که احتمالاً میدونید، Bun یک JavaScript Runtime مدرنه که با تمرکز روی سرعت ساخته شده. این پروژه در ابتدا با Zig توسعه پیدا کرد؛ چون Zig به یک تیم کوچک اجازه میداد بدون سربار Garbage Collector و Runtimeهای سنگین، خیلی سریع یک Runtime پرسرعت بسازه. دسترسی مستقیم به حافظه، سادگی زبان و تعامل خوب با C باعث شد معماری و طراحی سطح پایین Bun حول Zig شکل بگیره؛ موضوعی که Jarred Sumner، خالق Bun، هم بارها بهش اشاره کرده.
اما در ماه می امسال، تیم Bun اعلام کرد که قصد داره کل پروژه رو به Rust مهاجرت بده. حالا این بازنویسی انجام شده و کدهای Rust هم وارد شاخه اصلی پروژه شدن. نکتهی عجیب اینجاست که تقریباً تمام این کدها توسط Claude Code تولید شدن و علاوه بر بازنویسی، تعدادی از باگهای قدیمی هم در همین فرآیند برطرف شدن.
آیا مشکل از Zig بود؟
از نگاه تیم Bun، مشکل اصلی خود Zig نبود؛ بلکه مدیریت دستی حافظه در کنار Garbage Collector جاوااسکریپت بود. این ترکیب باعث نشت حافظه، کرش و هزینهی بالای نگهداری کد میشد و با بزرگتر شدن پروژه، اتکا به دقت برنامهنویس دیگر کافی نبود.
با این حال، جرد تأکید میکنه که Zig نقش مهمی در موفقیت اولیه Bun داشته و بخش بزرگی از معماری و عملکرد فعلی پروژه مدیون همون انتخاب اولیه است.
در مقابل، اندرو کلی، خالق Zig، بارها گفته مشکل از زبان Zig نبوده، بلکه از نحوهی استفادهی Bun از اون بوده. حتی جایی گفته بود داخل تیم Zig، از Bun بهعنوان مثالی استفاده میکنیم که «چطور نباید با Zig برنامه نوشت».
چرا Rust؟
بخش بزرگی از باگهای Bun به مدیریت حافظه مربوط میشد. در Rust این دسته از خطاها معمولاً هنگام کامپایل شناسایی میشن و مکانیزم Ownership و Drop هم آزادسازی حافظه رو مدیریت میکنن. در نتیجه، به جای اینکه توسعهدهنده همیشه مراقب همهچیز باشه، کامپایلر جلوی بخش زیادی از اشتباهات رو میگیره.
البته بازنویسی پروژهای با بیش از ۵۳۵ هزار خط کد Zig اصلاً تصمیم سادهای نبود. انجام دستی این کار حداقل یک سال زمان میبرد و عملاً توسعهی Bun رو متوقف میکرد. تیم ابتدا سعی کرد با Smart Pointerهای الهامگرفته از Rust و سختگیرتر کردن قوانین کدنویسی، مشکلات رو داخل Zig حل کنه، اما در نهایت تصمیم گرفت از Claude Code برای بازنویسی کامل پروژه استفاده کنه.
کلاد چطور این بازنویسی را انجام داد؟
جرد میگه ماجرا به سادگی این نبود که به Claude بگه «کل Bun رو به Rust تبدیل کن». قبل از شروع، ساعتها صرف طراحی Workflowها و استراتژی بازنویسی شد.
در نهایت، حدود ۵۰ Workflow مختلف به مدت ۱۱ روز تقریباً بدون توقف اجرا شدن؛ با هزینهای نزدیک به ۱۶۵ هزار دلار.
هر Workflow وظیفهی مشخصی داشت؛ از تبدیل الگوهای Zig به Rust و رفع خطاهای کامپایل گرفته تا اجرای
bun test و bun build. پاس کردن تستها و در نهایت Refactor کد.جرد هم بهجای اصلاح مستقیم خروجیها، Workflowها و Promptها رو بهبود میداد تا هر بار کیفیت خروجی بهتر بشه.
برای اعتماد به بیش از یک میلیون خط کد تولیدشده توسط هوش مصنوعی هم از روشی شبیه Code Review واقعی استفاده شد. یک Claude کد رو مینوشت و چند Claude دیگه، در Contextهای جداگانه، فقط وظیفه داشتن ایرادها و باگها رو پیدا کنن. نویسندهی کد Reviewer نبود و Reviewer هم اجازهی تغییر کد رو نداشت.
بعد از تبدیل همهی فایلها، مرحلهی اصلی یعنی رفع خطاها و پاس کردن تستها شروع شد. این چرخه بارها تکرار شد تا در نهایت تمام تستهای Bun روی همهی پلتفرمها با موفقیت پاس شدن و کد وارد شاخهی اصلی پروژه شد.
آیا این بازنویسی موفق خواهد بود؟
در کوتاهمدت احتمالاً بله. تستها مسیرهای اصلی رو پوشش میدن، نسخههای Canary مشکلات واضح رو پیدا میکنن و Rust هم بخش بزرگی از خطاهای مدیریت حافظه رو حذف میکنه.
اما سؤال اصلی بلندمدته.
اگر چند ماه بعد یک باگ پیچیدهی Concurrency یا یک حالت مرزی عجیب ظاهر بشه، مهندسی که مسئول دیباگ کردنشه با کدی روبهرو میشه که تقریباً هیچ انسانی اون رو بهطور کامل ننوشته یا خطبهخط درکش نکرده.
در نهایت، شرطبندی اصلی این پروژه نه روی Zig و Rust، بلکه روی این سؤاله که آیا یک Codebase عظیم که عمدتاً توسط هوش مصنوعی تولید شده، در بلندمدت هم قابل نگهداری و قابل اعتماد خواهد بود یا نه.
از طرف دیگه، بعضیها هم معتقدن این اتفاق فقط یک بازنویسی فنی نبوده و بخشی از یک کمپین بازاریابی برای Claude محسوب میشه.
پاسخ اینکه این تصمیم در نهایت موفق خواهد بود یا نه، فعلاً مشخص نیست؛ چیزی که فقط با گذر زمان معلوم میشه.
مقاله ای که خود جرد منتشر کرده و در مورد این تغییرات توضیح داده:
https://bun.com/blog/bun-in-rust
#News
@Syntax_fa
Bun
Rewriting Bun in Rust
Why & how we rewrote Bun from Zig to Rust
👍7❤5
معرفی telegram outreach
تو تلگرام یه سری تبلیغات میبینید که تو پیوی ارسال میشن.
این پروژه دقیقا همینکارو انجام میده.
اکانت های تلگرامی که دارید رو وارد میکنید و سشنشون ساخته میشه.
بعد میرید تسک میسازید که یوزر های کدوم گروه رو کراول کنه و لیمیت هارو مشخص میکنید مثلا 500 تا از یوزر های گروه سینتکس.
لیست ممبر های گروه رو نمیگیره. بجاش پیام های گروه رو استخراج میکنه و یوزر های فعالشون رو از این طریق پیدا میکنه.
بعدش مشخص میکنید که با کدوم اکانت ها به یوزر های کدوم گروه که تو مرحله قبلی بدست آوردید چه پیام هایی رو ارسال کنه.
پیام ها میتونه تکست باشه یا بصورت ویس باشه.
توی README پروژه نحوه استفاده ازش رو قرار دادیم.
لینک:
https://github.com/alireza-fa/telegram-outreach
@syntax_fa
تو تلگرام یه سری تبلیغات میبینید که تو پیوی ارسال میشن.
این پروژه دقیقا همینکارو انجام میده.
اکانت های تلگرامی که دارید رو وارد میکنید و سشنشون ساخته میشه.
بعد میرید تسک میسازید که یوزر های کدوم گروه رو کراول کنه و لیمیت هارو مشخص میکنید مثلا 500 تا از یوزر های گروه سینتکس.
لیست ممبر های گروه رو نمیگیره. بجاش پیام های گروه رو استخراج میکنه و یوزر های فعالشون رو از این طریق پیدا میکنه.
بعدش مشخص میکنید که با کدوم اکانت ها به یوزر های کدوم گروه که تو مرحله قبلی بدست آوردید چه پیام هایی رو ارسال کنه.
پیام ها میتونه تکست باشه یا بصورت ویس باشه.
توی README پروژه نحوه استفاده ازش رو قرار دادیم.
لینک:
https://github.com/alireza-fa/telegram-outreach
@syntax_fa
🔥12👎5❤1💩1
پکیج پایتونی gevent
چرا
قبل از اینکه کلمات کلیدی
استفاده از Threadهای سیستمعامل برای پایتون بسیار سنگین بود و حافظه زیادی مصرف میکرد. فریمورکهایی مثل Twisted هم بودند که بر اساس Callback کار میکردند، اما خواندن و دیباگ کردن کدهای آنها شبیه یک کابوس (Callback Hell) بود.
اینجا بود که
الان با وجود
با اینکه
اگر شما یک پروژه بزرگ جنگو (Django) یا فلسک (Flask) دارید که با کدهای معمولی نوشته شده، نمیتوانید یکشبه دهها هزار خط کد را به
مثال در سلری:
فرض کنید باید ۱۰۰ ایمیل بفرستید یا از ۱۰۰ سایت دیتا استخراج کنید (کارهای I/O Bound).اگر در Celery از حالت پیشفرض (Prefork/Processes) استفاده کنید و فقط ۲ عدد Worker داشته باشید، در هر لحظه فقط ۲ تسک انجام میشود. بقیه تسکها باید در صف منتظر بمانند تا این دو تمام شوند. این یعنی اتلاف زمان!
اما اگر Worker را با
celery
همان ۲ پروسس حالا میتوانند هر ۱۰۰ تسک را همزمان مدیریت کنند! وقتی تسک اول منتظر جواب سرور ایمیل است،
#gevent
@Syntax_fa
چرا
gevent اصلاً متولد شد؟قبل از اینکه کلمات کلیدی
async و await وارد پایتون شوند، برنامهنویسها برای مدیریت هزاران درخواست همزمان (مشکل C10k) یک دردسر بزرگ داشتند.استفاده از Threadهای سیستمعامل برای پایتون بسیار سنگین بود و حافظه زیادی مصرف میکرد. فریمورکهایی مثل Twisted هم بودند که بر اساس Callback کار میکردند، اما خواندن و دیباگ کردن کدهای آنها شبیه یک کابوس (Callback Hell) بود.
اینجا بود که
gevent با یک ایده درخشان وارد شد: کد را به شکل ساده و همگام (Sync) بنویس، اما ما آن را در پسزمینه به صورت ناهمگام (Async) و با سرعت نور اجرا میکنیم! gevent این کار را با استفاده از گرینلتها (Greenlets) که میکروتردهای بسیار سبکی در سطح C هستند، انجام داد.الان با وجود
asyncio، پرونده gevent بسته شده است؟با اینکه
asyncio استاندارد مدرن و آینده پایتون است، اما gevent هنوز یک برگ برنده بزرگ دارد: پروژههای قدیمی (Legacy).اگر شما یک پروژه بزرگ جنگو (Django) یا فلسک (Flask) دارید که با کدهای معمولی نوشته شده، نمیتوانید یکشبه دهها هزار خط کد را به
async/await تبدیل کنید. gevent با تکنیک Monkey Patching به شما اجازه میدهد بدون تغییر دادن حتی یک خط از منطق اصلی برنامهتان، عملکرد I/O سرور را چند برابر کنید.مثال در سلری:
فرض کنید باید ۱۰۰ ایمیل بفرستید یا از ۱۰۰ سایت دیتا استخراج کنید (کارهای I/O Bound).اگر در Celery از حالت پیشفرض (Prefork/Processes) استفاده کنید و فقط ۲ عدد Worker داشته باشید، در هر لحظه فقط ۲ تسک انجام میشود. بقیه تسکها باید در صف منتظر بمانند تا این دو تمام شوند. این یعنی اتلاف زمان!
اما اگر Worker را با
gevent اجرا کنید:celery
-A my_project worker -P gevent -c 100همان ۲ پروسس حالا میتوانند هر ۱۰۰ تسک را همزمان مدیریت کنند! وقتی تسک اول منتظر جواب سرور ایمیل است،
gevent سریعاً سراغ تسک دوم میرود. با کمترین مصرف رم و CPU، سرعت اجرای تسکهای شبکهای شما دهها برابر میشود.#gevent
@Syntax_fa
👍11❤3
🔥 اگه با Go کار میکنی و هنوز از Air استفاده نمیکنی، وقتشه نصبش کنی!
حتماً برات پیش اومده که بعد از هر تغییر توی کد، دوباره این دستور رو اجرا کنی:
بعد دوباره کد رو تغییر بدی، دوباره
اینجاست که
پکیج Air که یک ابزار Hot Reload برای Go هست که پروژه رو مانیتور میکنه و هر بار فایلی تغییر کنه، خودش برنامه رو دوباره Build و Run میکنه. یعنی فقط یک بار اجراش میکنی و تا آخر توسعه دیگه لازم نیست هی
📦 نصب:
🚀 اجرا:
اگه خواستی فایل تنظیماتش هم ساخته بشه:
با فایل
ریپو پروژه :
https://github.com/air-verse/air
#programming #backend #go
@Syntax_fa
حتماً برات پیش اومده که بعد از هر تغییر توی کد، دوباره این دستور رو اجرا کنی:
go run .
بعد دوباره کد رو تغییر بدی، دوباره
go run دوباره تغییر، دوباره اجرا...اینجاست که
Air وارد میشه.پکیج Air که یک ابزار Hot Reload برای Go هست که پروژه رو مانیتور میکنه و هر بار فایلی تغییر کنه، خودش برنامه رو دوباره Build و Run میکنه. یعنی فقط یک بار اجراش میکنی و تا آخر توسعه دیگه لازم نیست هی
go run بزنی.📦 نصب:
go install github.com/air-verse/air@latest
🚀 اجرا:
air
اگه خواستی فایل تنظیماتش هم ساخته بشه:
air init
با فایل
.air.toml هم میتونی مشخص کنی چه فایلهایی مانیتور بشن، چه پوشههایی نادیده گرفته بشن و دستور Build چطور اجرا بشه.ریپو پروژه :
https://github.com/air-verse/air
#programming #backend #go
@Syntax_fa
GitHub
GitHub - air-verse/air: ☁️ Live reload for Go apps
☁️ Live reload for Go apps. Contribute to air-verse/air development by creating an account on GitHub.
🔥7😁2❤1
تو دنیای برنامهنویسی برای چه کاری ساخته شدی؟
معمولاً بزرگترین دغدغهی کسایی که تازه میخوان وارد دنیای جذاب صفر و یک بشن اینه که: «اصلاً از کجا شروع کنم؟» بکاند؟ فرانتاند؟ هوش مصنوعی یا امنیت؟ تو این تست ما با چند تا سناریوی تحلیلی و ظریفِ روزمره، مدل ذهنی و شیوه حل مسئلهت رو میسنجیم تا بهت بگیم کدوم شاخه از دنیای نرمافزار، بیشترین هماهنگی رو با دیانای روانیت داره.
𝒁𝒆𝒓𝒗𝒂𝒏𝒂
معمولاً بزرگترین دغدغهی کسایی که تازه میخوان وارد دنیای جذاب صفر و یک بشن اینه که: «اصلاً از کجا شروع کنم؟» بکاند؟ فرانتاند؟ هوش مصنوعی یا امنیت؟ تو این تست ما با چند تا سناریوی تحلیلی و ظریفِ روزمره، مدل ذهنی و شیوه حل مسئلهت رو میسنجیم تا بهت بگیم کدوم شاخه از دنیای نرمافزار، بیشترین هماهنگی رو با دیانای روانیت داره.
𝒁𝒆𝒓𝒗𝒂𝒏𝒂
❤3🔥3
Syntax | سینتکس
تو دنیای برنامهنویسی برای چه کاری ساخته شدی؟ معمولاً بزرگترین دغدغهی کسایی که تازه میخوان وارد دنیای جذاب صفر و یک بشن اینه که: «اصلاً از کجا شروع کنم؟» بکاند؟ فرانتاند؟ هوش مصنوعی یا امنیت؟ تو این تست ما با چند تا سناریوی تحلیلی و ظریفِ روزمره، مدل…
حتی تو تستم بک اندم :(
پنج شیش سال پیش با نیت بک اند شروع کردم و هنوزم بک اندم.
البته دواپس هم کار کردم ولی فکر کنم محدود کسایی هستم که زیاد از این شاخه به اون شاخه نرفتم حالا نمیدونم تصمیم خوبی گرفتم یا نه
پنج شیش سال پیش با نیت بک اند شروع کردم و هنوزم بک اندم.
البته دواپس هم کار کردم ولی فکر کنم محدود کسایی هستم که زیاد از این شاخه به اون شاخه نرفتم حالا نمیدونم تصمیم خوبی گرفتم یا نه
😁9❤2