مقاله‌های رسمی

TDD چیه و چرا نوشتن تست قبل از کد، منطقی‌تر از چیزیه که به نظر می‌رسه

اولین باری که اسم Test-Driven Development رو می‌شنوی، احتمالاً به نظرت برعکس و غیرمنطقی میاد: چطور می‌شه تستی برای کدی نوشت که هنوز وجود نداره؟ ولی همین ترتیب برعکس، دقیقاً چیزیه که TDD رو از «نوشتن تست بعد از تموم شدن کد» متفاوت می‌کنه و یه سری مزیت واقعی به همراه داره که فقط با تجربه کردنش قابل درکه.

چرخه‌ی Red-Green-Refactor

TDD حول یه چرخه‌ی سه‌مرحله‌ای می‌چرخه که مدام تکرار می‌شه:

Red: اول یه تست می‌نویسی برای رفتاری که هنوز پیاده‌سازی نشده. طبیعتاً این تست fail می‌شه (قرمز)، چون کدی که قراره تستش کنه اصلاً وجود نداره.

Green: حالا کمترین و ساده‌ترین کد ممکن رو می‌نویسی تا فقط همون تست پاس بشه. نه بیشتر، نه optimized‌تر؛ فقط کافیه تست سبز بشه.

Refactor: با اطمینان از این‌که تست پاس می‌شه، حالا کد رو تمیز می‌کنی، duplicate ها رو حذف می‌کنی، اسم‌گذاری رو بهتر می‌کنی؛ بدون نگرانی از این‌که چیزی رو خراب کنی، چون تست بهت خبر می‌ده اگه رفتار عوض بشه.

# مرحله‌ی Red: تستی برای تابعی که هنوز وجود نداره
def test_calculate_discount():
    assert calculate_discount(100, "vip") == 85

# اجرا می‌کنیم: fail می‌شه چون calculate_discount تعریف نشده

# مرحله‌ی Green: کمترین کد برای پاس شدن تست
def calculate_discount(price, customer_type):
    if customer_type == "vip":
        return price * 0.85
    return price

# مرحله‌ی Refactor: حالا که تست داریم، می‌تونیم منطق رو تمیزتر کنیم
DISCOUNT_RATES = {"vip": 0.85, "regular": 0.95}

def calculate_discount(price, customer_type):
    rate = DISCOUNT_RATES.get(customer_type, 1.0)
    return price * rate

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

چرا این ترتیب مهمه

نکته‌ای که خیلی وقت‌ها نادیده گرفته می‌شه اینه که فایده‌ی اصلی TDD صرفاً «داشتن تست» نیست؛ چیزی که ارزش داره، تأثیریه که نوشتن تست قبل از کد روی طراحی می‌ذاره. وقتی مجبوری قبل از نوشتن پیاده‌سازی، مشخص کنی که تابعت چه ورودی‌هایی می‌گیره و چه خروجی‌ای برمی‌گردونه، به‌صورت طبیعی به سمت کدی می‌ری که interface ساده و قابل تست داره. کدی که تستش سخته (مثلاً به خاطر وابستگی‌های پنهون یا side effect های زیاد)، معمولاً همون کدیه که طراحیش هم ایراد داره.

این برعکس روشیه که خیلی از برنامه‌نویس‌ها عادت دارن: اول کد رو می‌نویسن، بعد سعی می‌کنن براش تست بنویسن. تو اون حالت، تست‌ها معمولاً فقط تأیید می‌کنن که کد چیکار می‌کنه (نه لزوماً چیزی که باید بکنه)، و چون کد از قبل نوشته شده، خیلی وقت‌ها طراحیش برای تست کردن مناسب نیست؛ مثلاً پر از متدهای استاتیک یا وابستگی مستقیم به دیتابیس.

یه مثال واقعی‌تر: سرویس ثبت‌نام کاربر

بیایم یه ویژگی رو با TDD پیش ببریم که واقعاً تو یه پروژه‌ی واقعی هم پیش میاد: سرویسی که یه کاربر جدید رو ثبت‌نام می‌کنه. این مثال عمداً یه dependency واقعی (دیتابیس) داره تا نشون بده TDD چطور طراحی رو به سمت قابل‌تست‌بودن هول می‌ده.

اول، قبل از نوشتن هیچ کدی، مشخص می‌کنیم سرویس به چه چیزی نیاز داره: یه repository برای چک کردن و ذخیره‌ی کاربر. این dependency رو از همون اول به‌صورت interface تزریق می‌کنیم، نه این‌که مستقیم داخل سرویس یه دیتابیس واقعی رو صدا بزنیم:

# قدم اول (Red): تستی برای رد کردن ایمیل تکراری
class FakeUserRepository:
    def __init__(self, existing_emails=None):
        self.existing_emails = existing_emails or set()
        self.saved_users = []

    def email_exists(self, email):
        return email in self.existing_emails

    def save(self, user):
        self.saved_users.append(user)

def test_rejects_duplicate_email():
    repo = FakeUserRepository(existing_emails={"ali@example.com"})
    service = UserRegistrationService(repo)

    result = service.register("ali@example.com", "password123")

    assert result.success is False
    assert result.error == "EMAIL_ALREADY_EXISTS"
    assert len(repo.saved_users) == 0

چون UserRegistrationService هنوز وجود نداره، این تست fail می‌شه. حالا کمترین کد ممکن رو می‌نویسیم تا سبز بشه:

# قدم دوم (Green)
class RegistrationResult:
    def __init__(self, success, error=None):
        self.success = success
        self.error = error

class UserRegistrationService:
    def __init__(self, repository):
        self.repository = repository

    def register(self, email, password):
        if self.repository.email_exists(email):
            return RegistrationResult(success=False, error="EMAIL_ALREADY_EXISTS")
        self.repository.save({"email": email, "password": password})
        return RegistrationResult(success=True)

حالا یه تست جدید برای قانون بعدی اضافه می‌کنیم؛ رد کردن پسورد ضعیف:

def test_rejects_weak_password():
    repo = FakeUserRepository()
    service = UserRegistrationService(repo)

    result = service.register("new@example.com", "123")

    assert result.success is False
    assert result.error == "PASSWORD_TOO_WEAK"
    assert len(repo.saved_users) == 0

def test_successful_registration_saves_user():
    repo = FakeUserRepository()
    service = UserRegistrationService(repo)

    result = service.register("new@example.com", "password123")

    assert result.success is True
    assert repo.saved_users[0]["email"] == "new@example.com"

با اضافه شدن این تست‌ها، سرویس رو گسترش می‌دیم:

# قدم سوم (Green + Refactor)
class UserRegistrationService:
    MIN_PASSWORD_LENGTH = 8

    def __init__(self, repository):
        self.repository = repository

    def register(self, email, password):
        if self.repository.email_exists(email):
            return RegistrationResult(success=False, error="EMAIL_ALREADY_EXISTS")
        if len(password) < self.MIN_PASSWORD_LENGTH:
            return RegistrationResult(success=False, error="PASSWORD_TOO_WEAK")
        self.repository.save({"email": email, "password": password})
        return RegistrationResult(success=True)

نکته‌ی مهم اینجا FakeUserRepository است. چون از همون اول تصمیم گرفتیم دیتابیس رو به‌صورت یه dependency قابل تزریق طراحی کنیم (نه این‌که مستقیم داخل سرویس به یه دیتابیس واقعی وصل بشیم)، تونستیم منطق ثبت‌نام رو کاملاً بدون نیاز به دیتابیس واقعی، سریع و ایزوله تست کنیم. این دقیقاً همون تأثیریه که TDD روی طراحی می‌ذاره: مجبورت می‌کنه از اول به شکل قابل‌تست فکر کنی.

مزیت‌هایی که معمولاً کمتر بهشون اشاره می‌شه

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

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

TDD موقع ساختن API

وقتی داری یه REST API می‌سازی، معمولاً با دو لایه‌ی متفاوت طرفی: منطق کسب‌وکار (business logic) و لایه‌ی HTTP که این منطق رو در قالب endpoint در معرض دید می‌ذاره. اشتباه رایج اینه که TDD رو مستقیم روی endpoint اجرا کنیم؛ یعنی تست بنویسیم که یه request واقعی به /api/users می‌فرسته و response رو چک می‌کنه. این کار می‌شه، ولی این‌جور تست‌ها کند هستن (چون سرور واقعی بالا میاد) و وقتی fail می‌شن، سخته بفهمی مشکل تو لایه‌ی HTTP بوده یا تو منطق کسب‌وکار.

روش بهتر، جدا کردن این دو لایه و تست کردن هر کدوم جداگانه‌ست. لایه‌ی business logic (مثل همون UserRegistrationService بالا) رو کاملاً بدون درگیر شدن با HTTP، با unit test پیش می‌بریم. بعد یه لایه‌ی نازک controller/route داریم که فقط مسئول parse کردن request و صدا زدن سرویسه:

# تست لایه‌ی HTTP، جدا از منطق کسب‌وکار
def test_register_endpoint_returns_201_on_success(test_client, mock_service):
    mock_service.register.return_value = RegistrationResult(success=True)

    response = test_client.post("/api/users", json={
        "email": "new@example.com",
        "password": "password123"
    })

    assert response.status_code == 201
    mock_service.register.assert_called_once_with("new@example.com", "password123")

def test_register_endpoint_returns_409_on_duplicate_email(test_client, mock_service):
    mock_service.register.return_value = RegistrationResult(
        success=False, error="EMAIL_ALREADY_EXISTS"
    )

    response = test_client.post("/api/users", json={
        "email": "existing@example.com",
        "password": "password123"
    })

    assert response.status_code == 409

اینجا mock_service جای سرویس واقعی نشسته، پس این تست‌ها فقط چک می‌کنن که controller درست request رو به سرویس پاس می‌ده و status code مناسب رو برمی‌گردونه؛ نه این‌که منطق ثبت‌نام درست کار می‌کنه یا نه (که قبلاً با unit test پوشش دادیمش). این جداسازی باعث می‌شه هم تست‌ها سریع اجرا بشن، هم وقتی چیزی fail می‌شه دقیقاً بدونی مشکل کجاست.

برای هر feature تست بنویسیم یا برای کل response؟

این سؤالی است که خیلی وقت‌ها موقع تست‌نویسی API پیش میاد، و جواب درست «هر دو، ولی تو دو سطح متفاوت» است، نه انتخاب یکی به‌جای اون یکی.

بخش اصلی تست‌ها باید سطح feature/قانون کسب‌وکار باشن؛ یعنی همون چیزی که تو مثال UserRegistrationService دیدیم: یه تست برای ایمیل تکراری، یه تست برای پسورد ضعیف، یه تست برای ثبت‌نام موفق. این تست‌ها سریع هستن، نیازی به بالا اومدن سرور واقعی ندارن، و وقتی fail می‌شن دقیقاً مشخصه کدوم قانون شکسته. اگه فقط به تست کردن کل response اکتفا کنی، وقتی یه تست fail بشه فقط می‌فهمی «یه جای ثبت‌نام خراب شده»، نه این‌که دقیقاً کدوم قانون.

در کنارش، به تعداد کمتر، به تست‌هایی هم نیاز داری که واقعاً endpoint رو صدا بزنن و کل response رو چک کنن؛ status code، شکل JSON خروجی، هدرها. این تست‌ها چیزهایی رو می‌گیرن که unit test نمی‌تونه: مسیر اشتباه تو routing، خطای serialize شدن، middleware ای که درست کار نمی‌کنه، یا auth ای که درست وصل نشده. این تست‌ها تضمین می‌کنن که تکه‌ها واقعاً با هم درست کار می‌کنن، نه فقط هر کدوم جدا.

یه ترکیب عملی که خوب جواب می‌ده اینه: به ازای هر قانون کسب‌وکار یا حالت مرزی، یه unit test (که تعدادشون زیاده و ارزون تمومن)، و به ازای هر route فقط چند تا تست سطح endpoint (یه مسیر موفق، و یکی دو تا از رایج‌ترین حالت‌های خطا) که فقط تأیید می‌کنن سیم‌کشی بین لایه‌ها درسته. این دقیقاً همون ایده‌ی test pyramid است که چند پاراگراف پایین‌تر بهش می‌رسیم؛ یه عالمه تست باریک و سریع تو پایین، و یه لایه‌ی نازک‌تر از تست‌های گسترده‌تر روش.

علاوه بر این، برای API هایی که قرارداد مشخصی با کلاینت دارن (مثلاً یه فرانت‌اند جدا یا یه سرویس دیگه که ازش استفاده می‌کنه)، می‌تونی از contract test هم استفاده کنی؛ تستی که تضمین می‌کنه response API همیشه با یه schema مشخص (مثلاً OpenAPI) مطابقت داره، حتی اگه پیاده‌سازی داخلیش عوض بشه.

TDD موقع ساختن سرویس‌ها و میکروسرویس‌ها

تو معماری میکروسرویس، چالش اصلی TDD اینه که هر سرویس معمولاً به سرویس‌های دیگه یا زیرساخت‌های خارجی (message queue، دیتابیس، یه API خارجی) وابسته‌ست. اگه بخوای برای هر تست، این وابستگی‌های واقعی رو بالا بیاری، تست‌هات هم کند می‌شن و هم شکننده (چون یه قطعی موقت تو شبکه می‌تونه تست رو fail کنه، نه لزوماً باگ تو کدت).

راه‌حل رایج، جدا کردن تست‌ها به چند سطح:

Unit test با fake/mock: درست مثل مثال بالا، منطق داخلی سرویس رو با نسخه‌های fake از وابستگی‌های بیرونی تست می‌کنیم. این تست‌ها سریع‌ترین و پرتکرارترین بخش هستن.

Integration test محدود: یه لایه‌ی بالاتر، جایی که سرویس واقعاً به یه نسخه‌ی تست از دیتابیس یا message broker وصل می‌شه (مثلاً با Docker) تا مطمئن بشیم کدی که با اون زیرساخت حرف می‌زنه (مثل query های SQL یا serialize کردن پیام) درست کار می‌کنه. این تست‌ها کندترن، پس تعدادشون معمولاً خیلی کمتر از unit test هاست.

Contract test بین سرویس‌ها: وقتی سرویس A از سرویس B استفاده می‌کنه، به‌جای این‌که تو تست‌های سرویس A واقعاً سرویس B رو صدا بزنی، یه قرارداد مشخص (مثلاً با Pact) تعریف می‌کنی که هر دو طرف بهش پایبند می‌مونن. این باعث می‌شه بتونی سرویس‌ها رو مستقل از هم توسعه و deploy کنی، بدون این‌که برای هر تغییر کوچیک مجبور باشی کل زنجیره رو بالا بیاری.

این هرم (تعداد زیاد unit test، تعداد متوسط integration test، و تعداد کم contract/end-to-end test) دقیقاً همون چیزیه که به‌عنوان test pyramid شناخته می‌شه، و TDD معمولاً بیشترین کاربردش رو تو پایین‌ترین لایه‌ی این هرم، یعنی unit test ها داره.

کجا TDD به‌سختی جواب می‌ده

TDD همیشه ابزار مناسبی نیست. برای کدی که ماهیتش اکتشافیه (مثلاً وقتی داری با یه API خارجی آشنا می‌شی یا یه پروتوتایپ سریع می‌سازی تا ببینی یه ایده اصلاً شدنیه یا نه)، نوشتن تست قبل از این‌که بدونی حتی چه شکلی قراره باشه راه‌حل نهایی، می‌تونه بیشتر وقت‌گیر باشه تا مفید. همین‌طور برای UI هایی که رفتارشون بیشتر بصریه تا منطقی، نوشتن تست‌های یونیت خیلی وقت‌ها کمک چندانی نمی‌کنه و باید سراغ ابزارهای دیگه‌ای مثل تست‌های end-to-end یا visual regression رفت.

یه اشتباه رایج دیگه اینه که تیم‌ها سعی می‌کنن TDD رو صددرصد و برای هر خط کد اجرا کنن، در حالی که هدف اصلی این نیست که هر تابعی حتماً از قبل تست داشته باشه، بلکه اینه که فرآیند فکر کردن قبل از نوشتن کد، طراحی بهتری بسازه. جایی که این فرآیند فایده نداره (مثل کد اکتشافی یا اسکریپت یک‌بار مصرف)، اصراف روی TDD فقط باعث کندی بدون سودِ متناسب می‌شه.

OpenAI محدودیت چت متنی رو برای کاربران رایگان ChatGPT برداشت

اوپن‌ای‌آی یکی از قدیمی‌ترین محدودیت‌های ChatGPT رو کنار گذاشت: از هفته‌ی آینده، کاربران رایگان (Free) و همچنین کاربران پلن Go دیگه هیچ محدودیتی برای چت‌های متنی نخواهند داشت. این تغییر دقیقاً بعد از اعلام اینکه ChatGPT به مرز یک میلیارد کاربر هفتگی رسیده، اعلام شده و یکی از بزرگ‌ترین آپدیت‌های کاربردی چند ماه اخیر این شرکته.

چه چیزی دقیقاً تغییر می‌کنه

تا الان، کاربران پلن رایگان اگه تو یه بازه‌ی زمانی کوتاه پیام زیادی می‌فرستادن، به یه سقف مصرف برخورد می‌کردن و مجبور می‌شدن یا صبر کنن یا برای ادامه‌ی کار به پلن پولی ارتقا بدن. با این تغییر، این محدودیت برای مکالمات متنی (text-based) کاملاً برداشته می‌شه. مهمه بدونی این «نامحدود» فقط شامل چت‌های متنیه؛ محدودیت‌ها برای آپلود فایل، تولید تصویر، حالت صوتی و سایر ابزارها هنوز به قوت خودشون باقی می‌مونن.

همزمان با این تغییر، مدل پیش‌فرض کاربران Free و Go هم عوض می‌شه: مدل GPT-5.5 Instant کنار می‌ره و جاش رو مدلی به اسم GPT-5.6 Luna می‌گیره. طبق اعلام اوپن‌ای‌آی، تو تست‌های داخلی، این مدل نسبت به GPT-5.5 Instant حدود ۶۲ درصد خطای کمتری تو پاسخ‌های واقعی (factual errors) داشته.

یه ویژگی جدید دیگه هم به اسم دکمه‌ی «Think» به تجربه‌ی کاربران رایگان اضافه می‌شه که بهشون اجازه می‌ده برای سؤال‌های سخت‌تر، سطح استدلال بالاتری رو فعال کنن. طبق برنامه‌ی اعلام‌شده، مدل GPT-5.6 Luna همین هفته جایگزین مدل قبلی می‌شه، ولی چت نامحدود و دکمه‌ی Think هفته‌ی بعد در دسترس قرار می‌گیرن.

این آپدیت فقط برای کاربران رایگان نیست

کاربران پلن Plus و Pro هم بی‌نصیب نموندن. اون‌ها از همین امروز به نسخه‌ی به‌روزشده‌ی مدل GPT-5.6 Sol دسترسی دارن؛ مدلی که طبق تست‌های داخلی اوپن‌ای‌آی، نسبت به GPT-5.5 Instant حدود ۶۸ درصد خطای کمتری داشته و پاسخ‌هاش هم فشرده‌تر و بدون فرمت‌بندی اضافیه. علاوه بر این، یه اسلایدر جدید هم به کاربران Plus و Pro اضافه شده که می‌تونن با اون میزان «فکر کردن» مدل رو برای هر پاسخ تنظیم کنن؛ از حالت سریع برای سؤال‌های ساده تا حالت عمیق‌تر برای کدنویسی و برنامه‌ریزی چندمرحله‌ای.

نکته‌ی مهم اینه که این نسخه‌ی به‌روزشده‌ی GPT-5.6 Sol فقط برای تجربه‌ی چت معمولی اعمال شده؛ نسخه‌ای که تو ChatGPT Work و Codex استفاده می‌شه، تغییری نکرده.

اصول SOLID: چیزی که همه ازش اسم می‌برن ولی کمتر کسی درست ازش استفاده می‌کنه

اصول SOLID احتمالاً یکی از پرتکرارترین موضوعاتی هست که تو مصاحبه‌های برنامه‌نویسی ازش سؤال می‌شه، ولی همین تکرار زیاد باعث شده خیلی وقت‌ها به یه سری تعریف حفظی تبدیل بشه که کسی واقعاً نمی‌دونه کِی و چرا باید ازشون استفاده کنه. این پنج اصل، راهنمای طراحی کلاس‌ها و ماژول‌ها هستن که هدفشون کد قابل نگهداری‌تر و کمتر شکننده در برابر تغییره؛ نه یه سری قانون مقدس که باید همیشه و همه‌جا کورکورانه اجراشون کنی.

S — Single Responsibility Principle

این اصل می‌گه هر کلاس باید فقط یه دلیل برای تغییر کردن داشته باشه. مثال کلاسیکش یه کلاس Invoice هست که هم منطق محاسبه‌ی قیمت رو داره، هم منطق ذخیره‌سازی تو دیتابیس، و هم منطق چاپ فاکتور:

class Invoice:
    def calculate_total(self):
        # منطق محاسبه‌ی قیمت
        pass

    def save_to_db(self):
        # منطق ذخیره‌سازی
        pass

    def print_invoice(self):
        # منطق چاپ
        pass

مشکل این طراحی اینه که سه تا دلیل کاملاً مستقل برای تغییر این کلاس وجود داره: تغییر منطق قیمت‌گذاری، تغییر نوع دیتابیس، و تغییر فرمت چاپ. اگه این‌ها رو جدا کنیم به Invoice، InvoiceRepository و InvoicePrinter، هر کدوم فقط با یه دلیل مشخص تغییر می‌کنن و تست کردنشون هم ساده‌تر می‌شه.

نکته‌ای که خیلی وقت‌ها اشتباه فهمیده می‌شه اینه که SRP به معنی «هر کلاس فقط باید یه متد داشته باشه» نیست؛ منظور اینه که همه‌ی متدهای یه کلاس باید حول یه مسئولیت واحد بچرخن.

O — Open/Closed Principle

این اصل می‌گه کد باید برای extension باز باشه ولی برای modification بسته. یعنی وقتی یه رفتار جدید اضافه می‌کنی، نباید مجبور بشی کد قدیمی و تست‌شده رو دستکاری کنی. مثال رایجش محاسبه‌ی تخفیفه:

# طراحی بد: هر تخفیف جدید یعنی تغییر این تابع
def calculate_discount(customer_type, price):
    if customer_type == "regular":
        return price * 0.95
    elif customer_type == "vip":
        return price * 0.85
    # هر مشتری جدید یعنی یه elif دیگه

# طراحی خوب: با polymorphism
class DiscountStrategy:
    def apply(self, price):
        raise NotImplementedError

class VipDiscount(DiscountStrategy):
    def apply(self, price):
        return price * 0.85

class RegularDiscount(DiscountStrategy):
    def apply(self, price):
        return price * 0.95

Next.js 16.3 منتشر شد؛ تجربه توسعه بهتر شده

اگر چند ماه با یک پروژه‌ی واقعی Next.js کار کرده باشی، احتمالاً با چند دردسر آشنا هستی.

همان لحظه‌ای که پروژه بزرگ‌تر می‌شود، next dev دیگر مثل روزهای اول سبک نیست. یک تغییر کوچک در کد ممکن است باعث شود چند ثانیه منتظر بمانید تا همه چیز دوباره آماده شود. Buildهای CI طولانی‌تر می‌شوند و روی بعضی سیستم‌ها حتی باز کردن پروژه تبدیل به یک تست صبر می‌شود.

Next.js 16.3 دقیقاً روی همین مشکلات دست گذاشته است.

ما قبلا یکسری از آپدیت هایی که خود وبسایت نکست داده بود را بررسی کردیم مثل instant navigation, Ai Improvements و تغییرات توربو پک. نکته‌ی جالب اینجاست که بخش زیادی از این تغییرات بدون اینکه حتی یک خط کد پروژه‌ات را تغییر بدی فعال می‌شوند.

یعنی ممکن است فقط با تغییر نسخه‌ی Next.js، همان پروژه‌ی قبلی سریع‌تر اجرا شود.

بهبودهایی که همین امروز روی پروژه‌های موجود تأثیر می‌گذارند

بخش مهم معرفی Next.js 16.3 همین جمله است: این نسخه برای پروژه‌های موجود هم بهبود دارد.

معمولاً وقتی یک نسخه‌ی جدید منتشر می‌شود، اولین سوال این است که «چه API جدیدی اضافه شده؟»

اما این بار سوال بهتر این است که:

«توی پروژه‌ی فعلی من چه چیزی بهتر می‌شود؟»

جواب کوتاه:

مصرف کمتر RAM در حالت توسعه

Consistent Hashing: چطور یه سیستم توزیع‌شده رو در برابر اضافه و کم شدن سرور مقاوم می‌کنه

فرض کن یه سیستم کش داری با ۴ تا سرور، و برای اینکه بدونی هر کلید (key) رو روی کدوم سرور بذاری، از یه hash ساده استفاده می‌کنی: server = hash(key) % 4. این روش تا وقتی تعداد سرورها ثابت بمونه خوب کار می‌کنه. ولی همین که یه سرور اضافه یا حذف کنی و عدد ماژول از ۴ به ۵ تغییر کنه، تقریباً تمام کلیدها به یه سرور جدید map می‌شن. یعنی کل کش تو یه لحظه بی‌اعتبار می‌شه و همه‌ی درخواست‌ها یهو به سراغ دیتابیس اصلی می‌رن؛ اتفاقی که به‌عنوان cache stampede شناخته می‌شه و می‌تونه دیتابیس رو زیر فشار له کنه.

ایده‌ی consistent hashing

Consistent hashing این مشکل رو با یه ترفند مفهومی حل می‌کنه: به‌جای ماژول گرفتن از تعداد سرورها، هم کلیدها و هم سرورها رو روی یه حلقه‌ی دایره‌ای (معمولاً با بازه‌ی ۰ تا ۲۳۲-۱) hash می‌کنیم. برای پیدا کردن این‌که یه کلید باید روی کدوم سرور بشینه، از نقطه‌ی مربوط به اون کلید روی حلقه شروع می‌کنیم و در جهت عقربه‌های ساعت حرکت می‌کنیم تا به اولین سرور برسیم.

نکته‌ی کلیدی اینجاست: وقتی یه سرور جدید اضافه یا حذف بشه، فقط کلیدهایی که بین اون سرور و همسایه‌ی قبلیش روی حلقه قرار دارن جابه‌جا می‌شن، نه همه‌ی کلیدها. به زبون ریاضی، اضافه یا حذف یه node، به‌طور میانگین فقط K/N از کلیدها رو جابه‌جا می‌کنه (که K تعداد کل کلیدها و N تعداد سرورهاست)، به‌جای تقریباً همه‌ی کلیدها.

import hashlib
import bisect

class ConsistentHash:
    def __init__(self, nodes=None, replicas=100):
        self.replicas = replicas
        self.ring = {}
        self.sorted_keys = []
        for node in nodes or []:
            self.add_node(node)

    def _hash(self, key):
        return int(hashlib.md5(key.encode()).hexdigest(), 16)

    def add_node(self, node):
        for i in range(self.replicas):
            h = self._hash(f"{node}-{i}")
            self.ring[h] = node
            bisect.insort(self.sorted_keys, h)

    def remove_node(self, node):
        for i in range(self.replicas):
            h = self._hash(f"{node}-{i}")
            del self.ring[h]
            self.sorted_keys.remove(h)

    def get_node(self, key):
        h = self._hash(key)
        idx = bisect.bisect(self.sorted_keys, h) % len(self.sorted_keys)
        return self.ring[self.sorted_keys[idx]]

قضیه‌ی CAP: چرا هیچ دیتابیس توزیع‌شده‌ای نمی‌تونه همه‌چیز رو با هم داشته باشه

یه بار که داری بین چند تا دیتابیس توزیع‌شده (مثل Cassandra، MongoDB، یا CockroachDB) یکی رو انتخاب می‌کنی، دیر یا زود به یه جمله می‌رسی که همه جا تکرار می‌شه: «این دیتابیس CP هست» یا «اون یکی AP هست». اگه پشت این حرف‌ها ندونی چه مصالحه‌ای واقعاً داره اتفاق می‌افته، خیلی راحت ممکنه دیتابیسی رو انتخاب کنی که دقیقاً برعکس چیزیه که سیستمت بهش نیاز داره.

سه ضلع قضیه

قضیه‌ی CAP (که اریک برور اولین بار مطرحش کرد) می‌گه یه سیستم دیتابیس توزیع‌شده، وقتی network partition اتفاق می‌افته (یعنی ارتباط بین بخشی از node ها قطع می‌شه)، فقط می‌تونه یکی از این دو تا رو تضمین کنه، نه هر دو رو با هم:

Consistency: هر خواندنی، آخرین نوشته‌ی موفق رو برمی‌گردونه. یعنی همه‌ی node ها همیشه یه نسخه‌ی یکسان و به‌روز از داده رو نشون می‌دن.

Availability: هر درخواستی (چه خواندن، چه نوشتن) یه جواب دریافت می‌کنه، حتی اگه بعضی node ها از کار افتاده باشن. سیستم هیچ‌وقت با یه خطا جواب رد نمی‌ده.

ضلع سومِ قضیه، Partition tolerance است: توانایی سیستم برای ادامه‌ی کار حتی وقتی شبکه بین node ها قطع می‌شه. نکته‌ی مهم اینجاست که partition tolerance تو دنیای واقعی یه انتخاب نیست؛ شبکه دیر یا زود قطع می‌شه، پس هر سیستم توزیع‌شده‌ی واقعی باید partition tolerant باشه. این یعنی انتخاب واقعی همیشه بین C و A است، نه بین سه‌تا گزینه.

یعنی چی وقتی partition اتفاق می‌افته؟

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

اگه سیستم انتخاب کنه Consistency رو حفظ کنه (CP)، node یک باید درخواست رو رد کنه یا صبر کنه، چون نمی‌تونه مطمئن بشه node های دیگه هم همین مقدار رو دارن. کاربر یه خطا می‌گیره، ولی داده هیچ‌وقت inconsistent نمی‌شه.

اگه سیستم انتخاب کنه Availability رو حفظ کنه (AP)، node یک همون لحظه به کاربر جواب می‌ده و نوشتن رو قبول می‌کنه، حتی اگه ندونه node های دیگه چه مقداری دارن. بعداً وقتی partition برطرف شد، سیستم باید یه مکانیزم برای reconcile کردن این تناقض‌ها داشته باشه (مثلاً last-write-wins یا vector clocks).

DeepSeek-V4-Flash: مدلی که ادعا می‌کنه از نسخه‌ی Pro خودش هم جلو زده

دیپ‌سیک این بار یه کار عجیب کرده: نسخه‌ی ارزون و سبک‌ترش رو آپدیت کرده و حالا این نسخه‌ی سبک، تو خیلی از بنچمارک‌های agentic از نسخه‌ی گرون‌تر و اصلی خودش (V4-Pro) جلو زده. این دقیقاً برعکس چیزیه که معمولاً تو دنیای مدل‌های زبانی می‌بینیم، جایی که مدل‌های سبک‌تر همیشه یه قدم عقب‌تر از flagship خودشون هستن.

داستان از کجا شروع شد

اواخر آوریل، دیپ‌سیک سری V4 رو به‌صورت preview منتشر کرد؛ یه معماری Mixture-of-Experts با ۲۸۴ میلیارد پارامتر کل و فقط ۱۳ میلیارد پارامتر فعال در هر پاس، به همراه context window یک میلیون توکنی. دو نسخه اومد بیرون: V4-Pro برای بالاترین سطح توانایی، و V4-Flash به‌عنوان گزینه‌ی سریع‌تر و ارزون‌تر برای کارهایی که نیاز به سرعت و هزینه‌ی پایین دارن.

اتفاق جالب سی و یکم جولای افتاد. دیپ‌سیک بدون تغییر معماری یا اندازه‌ی مدل، فقط با یه دور post-training جدید، نسخه‌ی V4-Flash-0731 رو منتشر کرد. طبق گزارش‌ها، این نسخه تو هر ۹ تا بنچمارک agentic که تست شده، از V4-Pro-Preview جلو زده؛ از جمله یه جهش عجیب ۶۴۵ درصدی تو بنچمارک DeepSWE. جالب‌تر این‌که قیمت API هم همون قیمت قبلی موند، یعنی هر میلیون توکن ورودی حدود ۰.۱۴ دلار.

چرا این موضوع مهمه

نکته‌ای که این آپدیت رو از یه بهبود معمولی جدا می‌کنه، اینه که فقط با post-training (بدون تغییر پارامتر یا معماری) تونستن این‌قدر جهش تو کارهای agentic بگیرن. این یعنی خیلی از پتانسیل یه مدل، هنوز تو مرحله‌ی fine-tuning و alignment نهفته‌ست، نه صرفاً تو تعداد پارامترها. برای کسی که داره مدل انتخاب می‌کنه برای ساخت coding agent یا هر ابزار agentic دیگه، این یعنی باید مرتب benchmark ها رو چک کنه، چون رتبه‌بندی مدل‌ها می‌تونه خیلی سریع‌تر از چیزی که فکر می‌کنیم عوض بشه.

از نظر فنی، V4-Flash از یه ساختار attention ترکیبی (hybrid attention) برای پردازش context طولانی به‌صورت بهینه استفاده می‌کنه، و بر خلاف اسمش که «فلش» و سبک به نظر می‌رسه، تو دنیای واقعی مصرف حافظه‌ش هنوز چالش‌برانگیزه؛ همین موضوع باعث شده تیم‌های تحقیقاتی دیگه هم روش کار کنن. مثلاً یه تحقیق جداگانه با نام FlashMemory-DeepSeek-V4 نشون داده با اضافه کردن یه لایه‌ی ایندکس‌گذاری عصبی (که فقط بخش‌های حیاتی از KV cache رو پیش‌بینی و بارگذاری می‌کنه)، می‌شه به عملکردی نزدیک به V4-Flash رسید ولی با مصرف حافظه‌ای حدود ۱۳.۵ درصد نسخه‌ی اصلی.

Message Queue چیه و چرا هر برنامه‌نویسی باید باهاش آشنا باشه

یه سناریوی خیلی رایج رو تصور کن: کاربر روی دکمه «ثبت‌نام» کلیک می‌کنه، سرور باید یوزر رو تو دیتابیس بسازه، یه ایمیل خوش‌آمدگویی بفرسته، یه گزارش برای تیم مارکتینگ بسازه و شاید یه پیامک هم بده. اگه همه‌ی این کارها رو تو همون request-response انجام بدی، کاربر باید چند ثانیه منتظر بمونه تا SMTP جواب بده، و اگه سرویس ایمیل یه لحظه کند بشه یا قطع بشه، کل ثبت‌نام fail می‌شه. این دقیقاً جایی است که message queue وارد بازی می‌شه.

ایده‌ی اصلی چیه

به زبان ساده، message queue یه واسطه است بین بخشی از سیستم که کار رو تولید می‌کنه (producer) و بخشی که اون کار رو انجام می‌ده (consumer). به‌جای اینکه producer مستقیم consumer رو صدا بزنه و منتظر جواب بمونه، یه پیام رو تو صف می‌ذاره و می‌ره سراغ کار بعدی. consumer هر وقت آماده بود، پیام رو از صف برمی‌داره و پردازش می‌کنه.

این جدایی زمانی (decoupling) دقیقاً همون چیزی است که مشکل بالا رو حل می‌کنه. سرور فقط یه پیام کوچیک می‌فرسته به صف با مضمون «این یوزر ثبت‌نام کرد، کارهای بعدیش رو انجام بده» و بلافاصله به کاربر جواب می‌ده. یه worker جدا، پشت صحنه، ایمیل و پیامک و گزارش رو مدیریت می‌کنه. اگه سرویس ایمیل قطع باشه، پیام تو صف می‌مونه تا وقتی که سرویس برگرده.

چرا فقط یه تابع async کافی نیست

اینجا سؤال منطقی پیش میاد: چرا از یه thread pool یا background job ساده تو خود اپلیکیشن استفاده نکنیم؟ جواب اینه که queue واقعی چند تا امتیاز اضافه می‌ده که یه goroutine یا thread ساده نداره:

پایداری (durability): اگه سرور کرش کنه، پیام‌هایی که تو حافظه‌ی یه thread pool بودن از بین می‌رن. ولی پیام‌هایی که تو RabbitMQ یا Kafka نوشته شدن، روی دیسک persist می‌شن و بعد از ریستارت هم سر جاشون هستن.

مقیاس‌پذیری مستقل: می‌تونی producer و consumer رو کاملاً جدا از هم scale کنی. اگه صف پر شد، فقط تعداد worker ها رو زیاد می‌کنی، بدون اینکه به API لایه دست بزنی.

retry و backoff: اکثر broker ها مکانیزم retry دارن. اگه consumer یه لحظه fail بشه (مثلاً دیتابیس موقتاً در دسترس نبود)، پیام دوباره به صف برمی‌گرده و بعد از چند ثانیه دوباره تلاش می‌شه، بدون اینکه خودت این منطق رو از صفر بنویسی.

چند تا الگوی رایج

Rate Limiting: چرا هر API باید یک سقف مصرف داشته باشه

فرض کن یک endpoint ساده داری که لیست محصولات رو برمیگردونه. یک روز متوجه میشی سرورت زیر فشار عجیبی رفته، درحالی‌که تعداد کاربر واقعی زیاد نشده. وقتی لاگ‌ها رو نگاه میکنی، میبینی یک IP تنها، چند هزار درخواست در ثانیه فرستاده — یا یک اسکریپت خرابه، یا یک نفر داره عمداً داده‌هات رو میخراشه (scrape میکنه)، یا حتی داره تلاش میکنه با حجم درخواست سرویس رو از کار بندازه. rate limiting دقیقاً همون لایه‌ایه که جلوی این سناریو رو میگیره: تعیین میکنه هر کلاینت (بر اساس IP، کاربر، یا API key) توی یک بازه‌ی زمانی مشخص، حداکثر چند درخواست میتونه بفرسته.

چرا واقعاً مهمه

اولین و واضح‌ترین دلیل، محافظت از منابع سرور در برابر سوءاستفاده یا حملات است. حملات denial-of-service (چه عمدی چه ناشی از یک باگ توی کلاینت که وارد یک حلقه‌ی بی‌نهایت از درخواست شده) میتونن یک سرویس سالم رو در عرض چند ثانیه از پا دربیارن. rate limiting یک سقف مشخص میذاره که جلوی این نوع فشار رو میگیره، قبل از این‌که به لایه‌های عمیق‌تر سیستم (مثل دیتابیس) برسه.

دومی، توزیع عادلانه‌ی منابع بین کاربرهاست. اگه یک API عمومی داری که چند هزار کلاینت مختلف ازش استفاده میکنن، بدون rate limiting هیچ تضمینی نیست که یک کلاینت پرمصرف، کل ظرفیت سرور رو برای بقیه اشغال نکنه. با یک سقف مشخص برای هر کلاینت، مطمئن میشی هیچ‌کس نمیتونه سهم بقیه رو بخوره.

سومی، کنترل هزینه است، مخصوصاً وقتی endpoint پشت سرش یک سرویس گرون‌قیمت باشه — مثلاً یک API که هر درخواستش یک فراخوانی به یک مدل هوش مصنوعی یا یک سرویس ثالث پولی میفرسته. بدون سقف، یک باگ ساده توی کد کلاینت (مثلاً یک حلقه‌ی retry بی‌پایان) میتونه صورت‌حساب رو در عرض چند ساعت نجومی کنه.

چهارمی، جلوگیری از brute-force. روی endpoint هایی مثل لاگین، rate limiting جلوی این رو میگیره که یک مهاجم بتونه با امتحان‌کردن هزاران رمز عبور در ثانیه، حساب کاربری رو بشکنه.

الگوریتم‌های رایج rate limiting

چند روش استاندارد برای پیاده‌سازی rate limiting وجود داره، و هرکدوم trade-off متفاوتی دارن.

Fixed Window

ساده‌ترین روش: یک بازه‌ی زمانی ثابت (مثلاً هر دقیقه) در نظر میگیری و میشماری چند درخواست توش اومده. اگه از سقف رد بشه، بقیه رد میشن تا شروع بازه‌ی بعدی.

cuid و cuid2: چرا نسخه‌ی دوم عملاً از صفر بازنویسی شد

وقتی میخوای برای رکوردهای دیتابیست یک شناسه‌ی یکتا بسازی، احتمالاً اول به auto increment فکر میکنی، بعد به UUID، و اگه دنبال چیزی سبک‌تر و url-friendly تر باشی، به cuid میرسی. ولی نکته‌ای که خیلی وقت‌ها گم میشه اینه که cuid و cuid2 دو چیز کاملاً متفاوتن — نه یک آپدیت جزئی، بلکه یک بازطراحی کامل با فرض‌های امنیتی متفاوت.

cuid اصلی چی بود

cuid (نسخه‌ی اول) حدود سال ۲۰۱۲ ساخته شد تا یک جایگزین برای auto-increment ID و UUID باشه که هم یکتا باشه، هم قابل مرتب‌سازی بر اساس زمان تولید (chronologically sortable)، و هم برای استفاده توی URL راحت‌تر از UUID باشه (چون کوتاه‌تره و کاراکترهای عجیب مثل خط‌تیره‌ی اجباری UUID رو نداره).

ساختار یک cuid از چند بخش تشکیل شده: یک پیشوند ثابت (c)، timestamp، یک شمارنده (counter)، اطلاعاتی از fingerprint ماشین و پردازش (که شامل چیزهایی مثل هاست‌نیم و شناسه‌ی پردازش میشد)، و یک بخش تصادفی. مثال یک cuid واقعی این شکلیه:

cljk3f2j40000qzrmn831i7rn

چرا cuid کنار گذاشته شد

مشکل اصلی cuid وقتی خودش رو نشون داد که مسائل امنیتی جدی‌تری مطرح شد. چون بخشی از cuid از fingerprint ماشین (host/process info) و timestamp قابل پیش‌بینی ساخته میشه، این یعنی تا حدی میشه از روی خود ID، اطلاعاتی درباره‌ی زیرساخت سرور یا ترتیب دقیق تولید رکوردها استنباط کرد. علاوه بر این، چون بخش زمانی cuid قابل پیش‌بینیه، در برخی سناریوها میشه با حدس زدن IDها، رکوردهای مجاور رو enumerate کرد — دقیقاً همون چیزی که یک شناسه‌ی یکتا نباید اجازه بده.

مشکل دیگه، performance بود: تولید fingerprint ماشین و بعضی محاسبات cuid اصلی روی برخی محیط‌ها (مخصوصاً serverless که هر بار یک instance جدید بالا میاد) کند و ناسازگار عمل میکرد.

cuid2 چطور این مشکلات رو حل کرد

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

اول، امنیت رمزنگاری. cuid2 به‌جای تکیه به fingerprint قابل‌پیش‌بینی ماشین، از یک تابع هش امن (SHA3) روی ترکیبی از entropy تصادفی، timestamp، counter، و یک مقدار fingerprint ضعیف‌تر و کم‌اهمیت‌تر استفاده میکنه. نتیجه‌ی نهایی یک رشته‌ست که از نظر آماری غیرقابل‌پیش‌بینیه — یعنی حتی اگه بدونی الگوریتم چطور کار میکنه، نمیتونی ID بعدی رو حدس بزنی یا از روی یک ID موجود، ID های مجاورش رو enumerate کنی.

OpenAI قیمت GPT-5.6 رو شکست؛ دوران بی‌حساب‌وکتاب مصرف توکن داره تموم میشه

پنج‌شنبه‌ی گذشته، OpenAI اعلام کرد قیمت دو مدل از خانواده‌ی GPT-5.6 رو به‌طور قابل‌توجهی کاهش داده — این اتفاق فقط حدود سه هفته بعد از عرضه‌ی همین مدل‌ها افتاده، که خودش نشونه‌ی خوبیه از اینکه فشار رقابتی روی OpenAI چقدر واقعیه.

اعداد دقیق

خانواده‌ی GPT-5.6 از سه مدل تشکیل شده: Sol (پرچمدار)، Terra (رده‌ی میانی)، و Luna (سبک‌ترین و ارزون‌ترین نسخه). قیمت Luna، که پایین‌ترین رده‌ست، ۸۰ درصد کاهش پیدا کرده: از $1 به $0.20 روی هر میلیون توکن ورودی، و از $6 به $1.20 روی خروجی. Terra هم ۲۰ درصد ارزون‌تر شده: ورودی از $2.50 به $2 روی هر میلیون توکن، و خروجی از $15 به $12. قیمت Sol، مدل اصلی، بدون تغییر مونده.

این کاهش قیمت هم روی API اعمال شده و هم روی حساب‌های سازمانی مثل ChatGPT Work و Codex، یعنی استفاده از Luna و Terra حالا سهمیه‌ی کمتری مصرف میکنه، بدون این‌که قیمت اشتراک ماهانه تغییر کنه.

چرا این اتفاق افتاد

OpenAI این کاهش قیمت رو نتیجه‌ی بهینه‌سازی‌های گسترده در کل زیرساختش معرفی کرده: مسیریابی بهتر روی سخت‌افزار، نرم‌افزار inference بهینه‌تر، و الگوریتم‌های context-caching هوشمندتر که جلوی تکرار محاسبات قبلاً انجام‌شده رو توسط agent ها میگیره. نکته‌ی جالب‌تر اینه که بخشی از این بهینه‌سازی رو خود مدل Sol انجام داده — طبق گزارش OpenAI، این مدل به‌صورت خودکار kernel های تولیدی (production code kernels) رو بازنویسی کرده و همین کار به‌تنهایی حدود ۲۰ درصد از هزینه‌ی سرویس‌دهی رو کم کرده. این یعنی مدل داشته روی بهبود کارایی خودش کار میکرده، نه فقط روی پاسخ‌دادن به کاربر.

زمینه‌ی واقعی: فشار هزینه روی مشتری‌های سازمانی

پشت این تصمیم یک واقعیت بازار جدی‌تر هم هست. طبق گزارش CNBC، شرکت‌ها این روزها نسبت به هزینه‌های AI حساس‌تر از قبل شدن، چون خیلی از سازمان‌ها بدون تصویر روشنی از بازگشت سرمایه (ROI)، تمایلی به استقرار مدل‌های گرون‌قیمت ندارن. دوران اولیه‌ی ChatGPT رو بهش میگفتن دوران «tokenmaxxing» — جایی که کارفرماها کارمندها رو تشویق میکردن هرچقدر میخوان از AI استفاده کنن، بدون نگرانی درباره‌ی هزینه. حالا این دوران داره جای خودش رو به یک رویکرد حساب‌شده‌تر میده، و سم آلتمن، مدیرعامل OpenAI، اخیراً هزینه رو «یک مسئله‌ی بزرگ» توصیف کرده بود.

فشار رقابتی از سمت استارتاپ‌های چینی و رقبای بزرگ‌تر مثل مایکروسافت و گوگل هم نقش داره — همه‌شون دارن مدل‌های ارزون‌تر برای مشتری‌های سازمانی معرفی میکنن.

Elasticsearch: قدرتمند، سنگین، و نه همیشه انتخاب درست

خیلی وقت‌ها یک پروژه فقط به یک جستجوی ساده نیاز داره — کاربر یک کلمه تایپ میکنه و باید سریع نتیجه ببینه. اولین گزینه‌ای که معمولاً به ذهن میاد Elasticsearch است، چون اسمش همه‌جا هست و مستنداتش زیاده. ولی قبل از این‌که سراغش بری، ارزش داره بدونی این ابزار برای چه مقیاسی ساخته شده، چقدر منابع میخواد، و کِی یک جایگزین سبک‌تر تصمیم بهتریه.

Elasticsearch واقعاً چیه

Elasticsearch یک موتور جستجو و آنالیز توزیع‌شده‌ست که روی Apache Lucene ساخته شده. کارش فقط «پیدا کردن یک رشته توی متن» نیست؛ یک سیستم کامله برای indexing متن با امتیازدهی relevance، فیلتر کردن روی فیلدهای ساختاریافته، اجرای aggregation های پیچیده (مثل «میانگین قیمت به تفکیک دسته‌بندی»)، و مقیاس‌پذیری روی چند نود همزمان. برای همینه که توی سیستم‌های لاگ‌مانیتورینگ (مثل استک ELK)، جستجوی محصولات فروشگاه‌های بزرگ، و تحلیل داده‌ی حجیم این‌قدر رایجه.

چرا سنگین حساب میشه

مشکل اصلی Elasticsearch این نیست که کند باشه؛ مشکل اینه که برای اجرا شدن، منابع قابل توجهی میخواد. چون روی JVM (جاوا) اجرا میشه، حداقل نیاز به چند صد مگابایت تا چند گیگابایت heap memory داره، حتی برای یک نود توسعه‌ای کوچیک. توصیه‌ی رسمی برای یک نود production معمولاً از ۲ تا ۴ گیگابایت رم شروع میشه و برای دیتاست‌های بزرگ‌تر به‌سرعت بالا میره. علاوه بر این، Elasticsearch برای کار درست نیازمند تنظیمات سیستم‌عاملیه (مثل افزایش vm.max_map_count روی لینوکس)، و راه‌اندازی یک کلاستر واقعی (با نودهای master و data جدا) خودش یک پروژه‌ی مجزاست، نه یک نصب پنج‌دقیقه‌ای.

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

Meilisearch و رقبای سبک‌تر

Meilisearch یک موتور جستجوی متن‌باز است که با Rust نوشته شده و از ابتدا برای سادگی و سرعت راه‌اندازی طراحی شده، نه برای مقیاس عظیم. تفاوتش با Elasticsearch از همون لحظه‌ی نصب معلومه: یک باینری تک‌فایلی که بدون JVM، بدون تنظیمات پیچیده، و با مصرف رم بسیار پایین‌تر (معمولاً چند ده مگابایت برای دیتاست‌های متوسط) اجرا میشه. جستجوش هم به‌صورت پیش‌فرض typo-tolerant است — یعنی حتی اگه کاربر کلمه رو غلط تایپ کنه، نتیجه‌ی درست رو پیدا میکنه — بدون این‌که نیاز به تنظیم دستی داشته باشه.

ریپلیکیشن دیتابیس: یک کپی زنده از داده ها، همیشه آماده

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

مهمه که این رو از شاردینگ جدا کنی. توی شاردینگ، هر سرور فقط بخشی از داده رو داره. توی ریپلیکیشن، هر سرور (یا حداقل هر replica) یک کپی کامل از کل داده رو نگه میداره. این دو تکنیک هدف متفاوتی دارن و معمولاً با هم ترکیب میشن، نه جایگزین همدیگه.

چرا ریپلیکیشن میخوایم

دو دلیل اصلی برای ریپلیکیشن وجود داره، و هر کدوم مسئله‌ی متفاوتی رو حل میکنن.

اول، دسترس‌پذیری بالا (high availability). اگه سرور اصلی (که بهش primary یا master میگن) از کار بیفته، یکی از replica ها میتونه جاش رو بگیره و نقش primary جدید رو بازی کنه، بدون این‌که سرویس کامل قطع بشه. به این فرآیند failover میگن.

دوم، توزیع بار خواندن. توی خیلی از اپلیکیشن‌ها، تعداد خواندن (SELECT) خیلی بیشتر از نوشتن (INSERT/UPDATE) است. اگه همه‌ی این خواندن‌ها روی همون یک سرور primary انجام بشه، اون سرور زیر فشار میمونه. با ریپلیکیشن میتونی خواندن‌ها رو بین چند replica پخش کنی و فقط نوشتن‌ها رو روی primary نگه داری — الگویی که بهش read/write splitting میگن.

چطور داده از primary به replica میرسه

مکانیزم رایج این است که primary هر تغییری که روی داده‌اش اعمال میشه رو توی یک لاگ ترتیبی ثبت میکنه — توی PostgreSQL بهش WAL (Write-Ahead Log) میگن، توی MySQL بهش binlog. هر replica این لاگ رو از primary میخونه و همون تغییرات رو دقیقاً به همون ترتیب روی نسخه‌ی خودش اعمال میکنه. یعنی replica عملاً داره یک تاریخچه‌ی کامل از هر اتفاقی که روی primary افتاده رو دنبال میکنه و بازش تولید میکنه.

sync در مقابل async: معامله‌ای که باید آگاهانه انتخابش کنی

اینجا یکی از مهم‌ترین تصمیم‌های طراحی توی ریپلیکیشن پیش میاد: وقتی یک نوشتن روی primary اتفاق می‌افته، آیا باید صبر کنه تا replica هم همون نوشتن رو تأیید کنه، یا میتونه بدون منتظر موندن به کلاینت جواب «موفق» بده؟

Grok حالا برات اپلیکیشن کامل میسازه؛ آشنایی با Build Mode و grok.me

خیلی وقت‌ها یک ایده‌ی ساده توی ذهن آدم شکل میگیره — یک ماشین‌حساب مخصوص یک کار خاص، یک صفحه‌ی landing برای یک پروژه‌ی جانبی، یک داشبورد کوچیک برای دنبال کردن یک سری عدد — ولی چون کدنویسی بلد نیستی یا وقت راه‌اندازی محیط توسعه رو نداری، ایده همون‌جا میمونه. این دقیقاً همون شکافیه که SpaceXAI (همون شرکتی که قبلاً به اسم xAI میشناختیمش) با قابلیت جدید Grok به اسم Build Mode میخواد پرش کنه.

Build Mode چیه

Build Mode یک قابلیت تازه‌ست که همین چند روز پیش، ۲۸ ژوئیه ۲۰۲۶، برای مشترکین SuperGrok Heavy به‌صورت early beta فعال شد. ایده‌ش اینه که به‌جای این‌که Grok فقط یک تکه کد بهت بده که خودت باید کپی کنی و جایی اجرا کنی، مستقیم توی همون چت یک پیش‌نمایش زنده و کاملاً کاربردی از چیزی که خواستی میسازه. بعد میتونی با زبان طبیعی — نه با نوشتن کد — بگی چیدمان عوض بشه، رنگ‌ها تغییر کنه، یک ویژگی اضافه بشه، یا منطق برنامه فرق کنه.

این قابلیت روی وب (grok.com)، اپ iOS و اپ اندروید در دسترسه، یعنی محدود به یک پلتفرم خاص نیست.

چی میشه باهاش ساخت

طبق اعلام رسمی SpaceXAI، دامنه‌ی چیزهایی که Build Mode ازش پشتیبانی میکنه نسبتاً گسترده‌ست:

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

انتشار: لینک grok.me یا دامنه‌ی خودت

نکته‌ای که این قابلیت رو از خیلی از ابزارهای مشابه متمایز میکنه، بخش انتشاره. وقتی چیزی که ساختی آماده شد، میتونی با یک لینک به فرمت grok.me منتشرش کنی و مستقیم به هرکسی بفرستی، یا اگه دامنه‌ی اختصاصی داری، همون پروژه رو به دامنه‌ی خودت وصل کنی. یعنی مسیر از «ایده‌ی توی ذهن» تا «چیزی که یک آدرس واقعی داره و قابل اشتراک‌گذاریه» بدون نیاز به هاستینگ جداگانه یا تنظیمات دیپلوی طی میشه.

رقابتی که Grok تازه واردش شده

این حرکت SpaceXAI رو مستقیم وارد بازاری میکنه که این چند وقته اسمش شده «vibe coding» — رویکردی که در اون به‌جای نوشتن کد، با پرامپت و زبان طبیعی نرم‌افزار میسازی. رقبای این میدون کم نیستن: Google AI Studio که امکان تبدیل پرامپت به اپلیکیشن‌های native اندروید رو داره، Claude Artifacts خود آنتروپیک، و ChatGPT Codex از OpenAI. تفاوتی که Grok روش تأکید کرده اینه که میخواد این تجربه رو تا حد امکان غیرتخصصی نگه داره — بدون نصب محلی، بدون تنظیمات پیچیده، صرفاً پرامپت، پیش‌نمایش، و ویرایش.

شاردینگ دیتابیس: وقتی یک سرور دیگه جایی برای داده نداره

ایندکس و کش و replica خواندنی، همه تا یک جایی جواب میدن. اگه حجم داده‌ات آنقدر بزرگ بشه که حتی قوی‌ترین سرور دیتابیس هم دیگه جا نداشته باشه نگهش داره، یا نرخ نوشتن آنقدر بالا بره که یک سرور تنها نتونه جوابگو باشه، اون‌وقت با یک مسئله‌ی متفاوت روبه‌رو میشی. ایندکس کمکت میکنه سریع‌تر پیدا کنی، replica کمکت میکنه بار خواندن رو پخش کنی، ولی هیچ‌کدوم مشکل «داده آنقدر زیاده که روی یک ماشین جا نمیشه» رو حل نمیکنن. شاردینگ دقیقاً برای همین مسئله ساخته شده.

شاردینگ یعنی چی

شاردینگ یعنی داده‌ی یک جدول بزرگ رو به چند بخش (shard) تقسیم کنی و هر بخش رو روی یک سرور جدا نگه داری. برخلاف replication که هر سرور یک کپی کامل از کل داده رو داره، توی شاردینگ هر سرور فقط بخشی از داده رو داره. مثلاً اگه یک جدول کاربر با ۱۰۰ میلیون ردیف داری، میتونی کاربرهای با ID زوج رو روی یک سرور بذاری و کاربرهای با ID فرد رو روی سرور دیگه. حالا هر سرور فقط نصف داده رو مدیریت میکنه، و هم فضا و هم بار پردازشی بین دو ماشین تقسیم شده.

نکته‌ی مهم اینه که شاردینگ و replication دو مسئله‌ی متفاوت رو حل میکنن و معمولاً با هم ترکیب میشن: هر شارد خودش میتونه چند replica داشته باشه برای availability، و همزمان داده هم بین شاردهای مختلف تقسیم شده برای مقیاس‌پذیری.

چطور تصمیم بگیریم کدوم رکورد بره کدوم شارد

قلب هر سیستم شاردینگ، یک چیز به اسم shard key یا partition key است — ستونی که تعیین میکنه هر ردیف روی کدوم شارد قرار بگیره. چند استراتژی رایج برای این تصمیم وجود داره.

اولین و ساده‌ترین، range-based sharding است: بازه‌های مقدار رو بین شاردها تقسیم میکنی، مثلاً کاربرهایی با ID بین ۱ تا ۱ میلیون روی شارد اول، بین ۱ تا ۲ میلیون روی شارد دوم. مزیتش اینه که query هایی که روی یک بازه کار میکنن (مثل «همه‌ی سفارش‌های هفته‌ی گذشته») ممکنه فقط به یک شارد نیاز داشته باشن. مشکلش اینه که اگه داده به‌طور نامتوازن رشد کنه (مثلاً کاربرهای جدید همیشه ID بزرگ‌تر میگیرن)، شارد آخر همیشه شلوغ‌تر از بقیه میشه — به این پدیده hot shard میگن.

دومی hash-based sharding است: روی مقدار shard key یک تابع هش اجرا میکنی و نتیجه تعیین میکنه کدوم شارد. این روش توزیع خیلی یکنواخت‌تری میده و مشکل hot shard رو تا حد زیادی حل میکنه، ولی query هایی که روی بازه کار میکنن رو سخت‌تر میکنه، چون داده‌ی مرتبط ممکنه پخش بشه روی همه‌ی شاردها.

ایندکس دیتابیس: چرا یک کوئری ساده گاهی چند ثانیه طول میکشه

فرض کن یک جدول داری با یک میلیون ردیف، و میخوای کاربری با یک ایمیل مشخص رو پیدا کنی. بدون هیچ کمکی، دیتابیس مجبوره ردیف به ردیف کل جدول رو بگرده تا برسه به همونی که دنبالشی — به این کار میگن full table scan. روی یک میلیون ردیف، این یعنی دیتابیس تا آخرین لحظه هم نمیدونه جواب رو پیدا کرده یا نه، و باید همه‌چیز رو ببینه. حالا اگه همین جدول یک ایندکس روی ستون ایمیل داشته باشه، دیتابیس دیگه لازم نیست همه‌جا رو بگرده؛ مستقیم میره سراغ جایی که احتمال جواب هست. تفاوتش میتونه از چند ثانیه به چند میلی‌ثانیه برسه.

ایندکس چیه واقعاً

ساده‌ترین راه برای فهمیدن ایندکس، مقایسه‌اش با فهرست آخر یک کتابه. اگه بخوای بفهمی کلمه‌ی «recursion» توی کدوم صفحه‌ی کتاب اومده، دو راه داری: یا کتاب رو صفحه به صفحه بخونی تا پیداش کنی (همون full scan)، یا بری سراغ فهرست آخر کتاب که مرتب‌شده‌ست و سریع بگی صفحه‌ی ۲۴۳. ایندکس دیتابیس دقیقاً همین نقشو بازی میکنه: یک ساختار داده‌ی جدا و مرتب‌شده که به ازای هر مقدار توی یک ستون، میگه دقیقاً کجا (کدوم ردیف فیزیکی) باید بری دنبالش.

اکثر دیتابیس‌های رابطه‌ای مثل PostgreSQL و MySQL از یک ساختار داده به اسم B-tree برای ایندکس‌ها استفاده میکنن. B-tree یک درخت متوازنه که جستجو، درج، و حذف توش با پیچیدگی زمانی لگاریتمی انجام میشه — یعنی حتی روی یک جدول با میلیون‌ها ردیف، پیدا کردن یک مقدار فقط چند مرحله طول میکشه، نه میلیون‌ها مقایسه.

چرا رایگان نیست

اگه ایندکس این‌قدر خوبه، چرا همه‌ی ستون‌ها رو ایندکس نمیکنیم؟ چون هزینه داره، و این هزینه دو جا خودش رو نشون میده.

اول، فضا. هر ایندکس یک کپی جداگانه از داده‌ی اون ستون (به‌شکل ساختار درختی) نگه میداره. روی جدول‌های بزرگ، این میتونه چندین گیگابایت فضای اضافی مصرف کنه.

دوم و مهم‌تر، سرعت نوشتن. هر بار که یک ردیف جدید insert میکنی یا یک ردیف موجود رو update میکنی، دیتابیس باید همزمان با آپدیت کردن جدول اصلی، تمام ایندکس‌های مرتبط با اون ستون‌ها رو هم آپدیت کنه. اگه یک جدول پنج تا ایندکس داشته باشه، هر insert عملاً شش تا عملیات نوشتن رو تریگر میکنه، نه یکی. برای همین توصیه‌ی رایج اینه که فقط روی ستون‌هایی ایندکس بذاری که واقعاً توی WHERE، JOIN، یا ORDER BY زیاد ازشون استفاده میکنی — نه هر ستونی که «شاید یک روز» لازم بشه.

بخش	وضعیت	مقدار	بهبود
داشبورد Vercel	قبل	21.5 GB RAM	-
	بعد	2 GB RAM	~۹۰٪ کاهش مصرف حافظه
پروژه‌ی nextjs.org	قبل	4600 MB	-
	بعد	840 MB	کاهش محسوس مصرف حافظه

پروژه	Build سرد	Build با Cache	کاهش زمان	درصد بهبود
Nextjs.org	21 ثانیه	9.2 ثانیه	11.8 ثانیه	56.2%-
vercel.com/geist	30 ثانیه	5.5 ثانیه	24.5 ثانیه	81.7%-

وضعیت	عنوان	توضیح
قبل	Web Streams	Baseline
بعد	Native Node.js Streams	+22% Requests

ویژگی	cuid	cuid2
الگوریتم	fingerprint + timestamp + counter	SHA3 هش روی entropy تصادفی
قابل پیش‌بینی بودن	نسبتاً بله (ریسک امنیتی)	خیر
طول	ثابت	متغیر (پیش‌فرض ۲۴، قابل تنظیم ۴ تا ۳۲)
شروع رشته	حرف `c` ثابت	همیشه یک حرف تصادفی
عملکرد در serverless	ضعیف‌تر	بهینه‌شده
نگهداری پروژه	متوقف شده	فعال

مقاله‌های رسمی

TDD چیه و چرا نوشتن تست قبل از کد، منطقی‌تر از چیزیه که به نظر می‌رسه

چرخه‌ی Red-Green-Refactor

چرا این ترتیب مهمه

یه مثال واقعی‌تر: سرویس ثبت‌نام کاربر

مزیت‌هایی که معمولاً کمتر بهشون اشاره می‌شه

TDD موقع ساختن API

برای هر feature تست بنویسیم یا برای کل response؟

TDD موقع ساختن سرویس‌ها و میکروسرویس‌ها

کجا TDD به‌سختی جواب می‌ده

OpenAI محدودیت چت متنی رو برای کاربران رایگان ChatGPT برداشت

چه چیزی دقیقاً تغییر می‌کنه

این آپدیت فقط برای کاربران رایگان نیست

اصول SOLID: چیزی که همه ازش اسم می‌برن ولی کمتر کسی درست ازش استفاده می‌کنه

S — Single Responsibility Principle

O — Open/Closed Principle

Next.js 16.3 منتشر شد؛ تجربه توسعه بهتر شده

بهبودهایی که همین امروز روی پروژه‌های موجود تأثیر می‌گذارند

Consistent Hashing: چطور یه سیستم توزیع‌شده رو در برابر اضافه و کم شدن سرور مقاوم می‌کنه

ایده‌ی consistent hashing

قضیه‌ی CAP: چرا هیچ دیتابیس توزیع‌شده‌ای نمی‌تونه همه‌چیز رو با هم داشته باشه

سه ضلع قضیه

یعنی چی وقتی partition اتفاق می‌افته؟

DeepSeek-V4-Flash: مدلی که ادعا می‌کنه از نسخه‌ی Pro خودش هم جلو زده

داستان از کجا شروع شد

چرا این موضوع مهمه

Message Queue چیه و چرا هر برنامه‌نویسی باید باهاش آشنا باشه

ایده‌ی اصلی چیه

چرا فقط یه تابع async کافی نیست

چند تا الگوی رایج

Rate Limiting: چرا هر API باید یک سقف مصرف داشته باشه

چرا واقعاً مهمه

الگوریتم‌های رایج rate limiting

Fixed Window

cuid و cuid2: چرا نسخه‌ی دوم عملاً از صفر بازنویسی شد

cuid اصلی چی بود

چرا cuid کنار گذاشته شد

cuid2 چطور این مشکلات رو حل کرد

OpenAI قیمت GPT-5.6 رو شکست؛ دوران بی‌حساب‌وکتاب مصرف توکن داره تموم میشه

اعداد دقیق

چرا این اتفاق افتاد

زمینه‌ی واقعی: فشار هزینه روی مشتری‌های سازمانی

Elasticsearch: قدرتمند، سنگین، و نه همیشه انتخاب درست

Elasticsearch واقعاً چیه

چرا سنگین حساب میشه

Meilisearch و رقبای سبک‌تر

ریپلیکیشن دیتابیس: یک کپی زنده از داده ها، همیشه آماده

چرا ریپلیکیشن میخوایم

چطور داده از primary به replica میرسه

sync در مقابل async: معامله‌ای که باید آگاهانه انتخابش کنی

Grok حالا برات اپلیکیشن کامل میسازه؛ آشنایی با Build Mode و grok.me

Build Mode چیه

چی میشه باهاش ساخت

انتشار: لینک grok.me یا دامنه‌ی خودت

رقابتی که Grok تازه واردش شده

شاردینگ دیتابیس: وقتی یک سرور دیگه جایی برای داده نداره

شاردینگ یعنی چی

چطور تصمیم بگیریم کدوم رکورد بره کدوم شارد

ایندکس دیتابیس: چرا یک کوئری ساده گاهی چند ثانیه طول میکشه

ایندکس چیه واقعاً

چرا رایگان نیست

clustered در مقابل non-clustered

مقاله‌های رسمی

TDD چیه و چرا نوشتن تست قبل از کد، منطقی‌تر از چیزیه که به نظر می‌رسه

چرخه‌ی Red-Green-Refactor

چرا این ترتیب مهمه

یه مثال واقعی‌تر: سرویس ثبت‌نام کاربر

مزیت‌هایی که معمولاً کمتر بهشون اشاره می‌شه

TDD موقع ساختن API

برای هر feature تست بنویسیم یا برای کل response؟

TDD موقع ساختن سرویس‌ها و میکروسرویس‌ها

کجا TDD به‌سختی جواب می‌ده

OpenAI محدودیت چت متنی رو برای کاربران رایگان ChatGPT برداشت

چه چیزی دقیقاً تغییر می‌کنه

این آپدیت فقط برای کاربران رایگان نیست

اصول SOLID: چیزی که همه ازش اسم می‌برن ولی کمتر کسی درست ازش استفاده می‌کنه

S — Single Responsibility Principle

O — Open/Closed Principle

Next.js 16.3 منتشر شد؛ تجربه توسعه بهتر شده

بهبودهایی که همین امروز روی پروژه‌های موجود تأثیر می‌گذارند