مقالات

یه روز یکی از سرویس‌های داخلیت باید با یه سرویس دیگه حرف بزنه. مثلاً سرویس سفارش باید به سرویس پرداخت بگه «این سفارش رو تسویه کن». اولین راهی که به ذهن خیلی‌ها می‌رسه اینه: یه endpoint باز کن، یه API key هم بذار توش، تمام. مشکل از همینجا شروع میشه، چون «داشتن یه کلید» با «امن بودن ارتباط» فاصله‌ی زیادی داره.

قبل از هر چیز بذار یه چیزی رو روشن کنم: انتخاب پروتکل (REST، GraphQL، gRPC) اصلاً چیزی نیست که امنیت رو تضمین کنه. REST یه انتخاب کاملاً خوبه، ولی خود REST بودن هیچ ربطی به امن بودن نداره. امنیت از جای دیگه‌ای میاد: از اینکه چطور احراز هویت می‌کنی، چطور تصمیم می‌گیری کی به چی دسترسی داره، چطور داده رو رمزنگاری می‌کنی، چطور ورودی‌ها رو validate می‌کنی، و چقدر دو سیستم رو از هم ایزوله نگه می‌داری. این پنج تا با هم امنیت رو می‌سازن، نه انتخاب فرمت پیام.

معماری کلی، قبل از رفتن سراغ جزئیات

یه تصویر کلی از یه معماری معقول این شکلیه: سرویس A از طریق HTTPS به یه API Gateway یا reverse proxy می‌رسه، اونجا احراز هویت، تعیین دسترسی، rate limiting و محدودیت IP اعمال میشه، بعد درخواست به سرویس B واقعی می‌رسه، و در نهایت به دیتابیس. نکته‌ی مهم اینه که هیچ‌کدوم از این لایه‌ها به تنهایی کافی نیستن — این‌ها روی هم دفاع در عمق (defense in depth) رو می‌سازن. هدف طراحی یه سیستم «غیرقابل نفوذ» نیست (چنین چیزی وجود نداره)، هدف اینه که اگه یه لایه شکست خورد، بقیه‌ی سیستم خودکار قربانی نشه.

HTTPS اجباریه، نه اختیاری

این نکته آنقدر بدیهی به نظر می‌رسه که خیلی‌ها ازش رد می‌شن، ولی هنوز هم می‌بینم سرویس‌های داخلی که فقط چون «پشت فایروال هستن» با HTTP ساده کار می‌کنن. فرقی نمی‌کنه ترافیک بین دو تا دیتاسنتر رد بشه یا بین دو تا container توی یه کلاستر — بدون TLS، هر کسی که بین راه بایسته می‌تونه credential ها و داده‌ها رو بخونه. این یعنی همیشه https://api.example.com، هیچ‌وقت http://api.example.com، حتی برای ترافیک کاملاً داخلی.

برای ارتباط سرویس به سرویس، می‌تونی از این هم جلوتر بری و از mutual TLS (mTLS) استفاده کنی. توی TLS معمولی فقط کلاینت مطمئن میشه داره با سرور درست حرف می‌زنه؛ توی mTLS هر دو طرف certificate دارن و همدیگه رو verify می‌کنن. راه‌اندازیش توی Node.js با ماژول https این شکلیه:

const https = require('https');
const fs = require('fs');

const server = https.createServer({
  key: fs.readFileSync('server-key.pem'),
  cert: fs.readFileSync('server-cert.pem'),
  ca: fs.readFileSync('client-ca.pem'),
  requestCert: true,
  rejectUnauthorized: true,
}, (req, res) => {
  res.end('اتصال معتبره');
});

server.listen(443);

نکته‌ی requestCert: true و rejectUnauthorized: true اینجاست که اگه کلاینت certificate معتبر نداشته باشه، اصلاً اجازه‌ی وصل شدن پیدا نمی‌کنه — قبل از اینکه حتی یه خط از کد اپلیکیشنت اجرا بشه. برای API های داخلی حساس، mTLS یکی از قوی‌ترین گزینه‌هاست. مشکلش اینه که مدیریت certificate ها (تمدید، revoke کردن، rotate کردن) خودش یه پروژه‌ی جداست؛ اگه چند تا سرویس داری و مدیریتش برات سخته، ابزارهایی مثل service mesh (Istio، Linkerd) این کار رو خودکار می‌کنن.

از JWT کاربر برای ارتباط سرویس به سرویس استفاده نکن

یه اشتباه رایج اینه که همون JWT ای که برای احراز هویت کاربر نهایی صادر شده رو برای ارتباط بین دو تا سرویس backend هم دوباره‌کاری می‌کنن — یعنی چیزی شبیه Authorization: Bearer <user-jwt> رو بین سرویس‌ها پاس میدن. این کار مرز بین «هویت کاربر» و «هویت سرویس» رو از بین می‌بره و باعث میشه permission های کاربر و سرویس قاطی بشن. به جاش باید یه credential مخصوص machine-to-machine داشته باشی. گزینه‌های خوب اینجا شامل OAuth 2.0 Client Credentials، mTLS، درخواست‌های امضاشده (signed requests)، ترکیب API key و HMAC، و توکن‌های کوتاه‌مدت سرویس‌محور هستن.

برای بیشتر زیرساخت‌های متوسط، ترکیب OAuth 2.0 Client Credentials به‌همراه HTTPS انتخاب معقولیه؛ برای ارتباطات داخلی که واقعاً حساس هستن، mTLS به‌همراه توکن‌های کوتاه‌مدت گزینه‌ی قوی‌تریه.

هر سرویس هویت خودش رو داشته باشه

یه اشتباه دیگه که خیلی رایجه: یه کلید API واحد و master برای همه‌چیز. چیزی شبیه یه متغیر محیطی به اسم MASTER_API_KEY که همه‌ی سرویس‌ها ازش استفاده می‌کنن. مشکل این روش اینه که وقتی یکی از سرویس‌ها compromise بشه، عملاً کل سیستم compromise شده — چون همه از یه کلید استفاده می‌کردن.

راه درست‌تر اینه که هر سرویس یه service account مخصوص خودش داشته باشه، و به هر کدوم فقط همون permission هایی که واقعاً بهش نیاز داره داده بشه. مثلاً اگه سرویس A فقط باید کاربر بسازه و بخونه، نباید اصلاً امکان حذف کاربر یا دسترسی به بخش پرداخت رو داشته باشه:

سرویس A → مجاز به: create_user, read_user, update_access
سرویس A → غیرمجاز به: delete_user, access_payments, access_admin, access_database

به این اصل، least privilege میگن: هر جزء از سیستم فقط دسترسی‌ای رو داشته باشه که برای انجام کارش لازمه، نه بیشتر. این ساده‌ترین و در عین حال مؤثرترین اصلی هست که خیلی از تیم‌ها فراموشش می‌کنن.

احراز هویت با تعیین دسترسی فرق داره

احراز هویت (authentication) به این سؤال جواب میده: «تو کی هستی؟» و تعیین دسترسی (authorization) به این سؤال: «تو اجازه‌ی چه کاری رو داری؟» یه فرض اشتباه رایج اینه که فکر کنیم چون یه request احراز هویت شده، پس قابل اعتماده. این درست نیست. باید هر endpoint جداگانه چک بشه که آیا سرویسی که این درخواست رو فرستاده، مجوز انجام همین عملیات خاص رو داره یا نه. مثلاً POST /users ممکنه نیاز به مجوز user:create داشته باشه، در حالی که DELETE /users/:id ممکنه به یه مجوز کاملاً متفاوت نیاز داشته باشه که خیلی محدودتر بهش داده میشه.

امضای درخواست‌ها با HMAC

برای APIهایی که سطح امنیتی بالاتری می‌خوان، امضای درخواست (request signing) با HMAC یه لایه‌ی اضافه‌ی خیلی خوبیه. ایده اینه که هر دو سرویس یه secret مشترک دارن، و هر request قبل از ارسال با اون secret امضا میشه:

const crypto = require('crypto');

function signRequest(method, path, body, secret) {
  const timestamp = Date.now().toString();
  const payload = method + path + timestamp + JSON.stringify(body);
  const signature = crypto
    .createHmac('sha256', secret)
    .update(payload)
    .digest('hex');
  return { timestamp, signature };
}

این امضا معمولاً توی هدرهایی مثل این ارسال میشه:

X-Client-ID: service-a
X-Timestamp: 1760000000
X-Signature: a3f9c2...

سمت سرور، همین امضا دوباره از روی method، path، timestamp و body محاسبه میشه و با چیزی که تو header اومده مقایسه میشه. اگه یکی وسط راه request رو بگیره و مثلاً ایمیل داخل body رو عوض کنه، امضا دیگه match نمی‌کنه و request رد میشه — بدون اینکه اصلاً لازم باشه محتوای request رمزنگاری بشه؛ همین که تغییرناپذیریش تضمین بشه کافیه.

محافظت در برابر replay attack

فقط امضا کردن request کافی نیست. اگه کسی یه request معتبر و امضاشده رو ضبط کنه و بعداً دوباره همونو بفرسته، امضا هنوز معتبره چون چیزی توش عوض نشده. این همون replay attack هست. راه‌حلش ترکیب سه چیزه: timestamp، یه شناسه‌ی یکتا برای هر request (نان‌س یا request-id)، و امضا:

X-Timestamp: 1760000000
X-Request-ID: 550e8400-e29b-41d4-a716-446655440000
X-Signature: a3f9c2...

منطق سمت سرور این شکلیه: اول چک میشه timestamp توی یه بازه‌ی معقول هست (مثلاً کمتر از پنج دقیقه اختلاف با زمان فعلی سرور)، بعد چک میشه که این request-id قبلاً پردازش نشده (این بخش معمولاً با یه cache سریع مثل Redis پیاده میشه، با یه TTL برابر با همون بازه‌ی زمانی)، و اگه هر دو شرط برقرار بود، امضا verify میشه و در نهایت request-id ذخیره میشه تا دفعه‌ی بعد تکراری تشخیص داده بشه. بدون این مکانیزم، حتی امضای HMAC هم در برابر یه حمله‌ی ساده‌ی «ضبط و پخش دوباره» بی‌دفاعه.

شبکه رو محدود کن، این شاید مهم‌ترین قدمه

اگه سرویس B فقط قراره از طرف سرویس A صدا زده بشه، هیچ دلیلی نداره که اصلاً از اینترنت عمومی در دسترس باشه. این یکی از نکاتی هست که تأثیرش روی امنیت کلی سیستم از خیلی چیزهای دیگه بیشتره، چون هر لایه‌ی امنیتی دیگه‌ای که بذاری (authentication، rate limit، signature) باز هم در معرض حمله قرار می‌گیره اگه شبکه به‌طور عمومی باز باشه.

ابزارهایی که برای این کار به کار میان شامل قوانین فایروال، security group های ابری، شبکه‌ی خصوصی (VPC)، VPN یا WireGuard، IP allowlist، و DNS داخلی هستن. ایده‌آل اینه که ترافیک بین دو سرویس فقط از یه شبکه‌ی خصوصی رد بشه، نه از مسیر عمومی اینترنت که بعد پشت فایروال فیلتر بشه. این دو تا از نظر امنیتی خیلی با هم فرق دارن، حتی اگه نتیجه‌ی نهایی مشابه به نظر برسه.

هیچ‌وقت دسترسی مستقیم دیتابیس نده

یه اشتباه خطرناک که گاهی توی معماری‌های عجله‌ای دیده میشه اینه که یه سرویس بیرونی، مستقیماً credential دیتابیس سرویس دیگه رو داشته باشه. حتی اگه این credential محدود به یه کاربر readonly باشه، این کار لایه‌ی authorization اپلیکیشن رو کاملاً دور می‌زنه. مسیر درست همیشه از طریق API میگذره: سرویس A فقط باید از طریق HTTPS و API عمومی سرویس B باهاش حرف بزنه، و سرویس B خودش تصمیم می‌گیره که این عملیات با توجه به authorization چطور روی دیتابیس اجرا بشه. سرویس A هیچ‌وقت نباید بتونه کاری بیشتر از اونی که API صراحتاً exposed کرده انجام بده.

اعتماد کورکورانه به ورودی، حتی از سرویس داخلی

حتی اگه یه request از یه سرویس authenticated بیاد، بازم باید ورودی‌هاش validate بشن — schema، طول رشته‌ها، فرمت شناسه‌ها، URL ها، اسم فایل‌ها، enum ها، بازه‌ی عددی، و حجم payload. یه نکته‌ی خاص اینجا مربوط به SSRF هست: اگه سرور تو بر اساس یه URL که از سمت کاربر یا سرویس دیگه اومده (مثلاً یه فیلد callback_url) یه request جدید می‌سازه، بدون validate کردن اون آدرس ممکنه یه آسیب‌پذیری SSRF ایجاد بشه که مهاجم بتونه از طریق سرورت به منابع داخلی شبکه دسترسی پیدا کنه که اصلاً نباید بهشون دسترسی داشته باشه.

rate limit فقط برای ترافیک بیرونی نیست

یه سرویس authenticated لزوماً امن نیست. اگه سرویس A به هر دلیلی — یه باگ، یه حلقه‌ی بی‌نهایت، یه retry logic خراب — شروع کنه به بمباران کردن سرویس B، معتبر بودن token یا امضا هیچ کمکی نمی‌کنه. گذاشتن rate limit حتی روی ترافیک کاملاً داخلی، چیزیه که خیلی وقت‌ها دیر بهش فکر می‌کنیم؛ معمولاً بعد از اینکه یه بار یه سرویس داخلی کل کلاستر رو از پا درآورده. منطقی‌ترین کار اینه که برای هر endpoint بر اساس هزینه‌ی محاسباتیش یه سقف جدا تعریف کنی؛ یه request خواندنی ساده و یه عملیات export سنگین طبیعتاً نباید سقف یکسانی داشته باشن.

لاگ کردن، اما نه هر چیزی

وقتی یه چیزی خراب میشه، اولین جایی که سراغش میری لاگ‌هاست. صرفاً لاگ کردن مسیر و متد request (POST /users) کافی نیست؛ چیزهایی که واقعاً کمک‌کننده هستن شامل timestamp، اسم سرویس فرستنده، endpoint، شناسه‌ی یکتای request، نتیجه‌ی عملیات، تصمیم authorization، آدرس IP مبدأ، و latency میشن. نکته‌ی خیلی مهم اینه که هیچ‌وقت secret ها یا credential های حساس رو توی لاگ ننویسی — این خودش یه منبع رایج نشت اطلاعاته که کمتر بهش توجه میشه.

مقایسه‌ی روش‌های ارتباطی

انتخاب پروتکل بین دو سرویس بیشتر به الگوی استفاده بستگی داره تا امنیت، هرچند بعضی گزینه‌ها ذاتاً برای یه سناریوی خاص مناسب‌ترن:

برای ارتباط بین دو پلتفرم مستقل، REST به‌همراه HTTPS و OAuth2 (یا mTLS برای موارد حساس‌تر) یه انتخاب کاملاً محکمه. برای میکروسرویس‌های داخلی که تعداد زیادی درخواست کوچیک و پرتکرار با هم رد و بدل می‌کنن، gRPC یا یه message broker معمولاً منطقی‌تره.

نکته‌ای که در آخر ارزش تکرار کردن داره: هدف طراحی یه API که «هک کردنش غیرممکنه» نیست — چنین چیزی وجود خارجی نداره. هدف اینه که سیستم رو طوری بچینی که compromise شدن یه جزء، خودکار به compromise شدن همه‌چیز منجر نشه. ایزوله کردن شبکه، least privilege، credential های جداگانه برای هر سرویس، محدود کردن دسترسی دیتابیس، و دفاع در عمق، در عمل خیلی بیشتر از انتخاب REST یا GraphQL یا هر پروتکل دیگه‌ای روی امنیت واقعی سیستم تأثیر می‌ذارن.

آیا واستون سؤال شده که مثلاً ChatGPT یا Gemini چطوری با اینکه یه LLM هستن و منطقا فقط باید بتونن متن ورودی بگیرن، عکس شما رو می‌فهمن؟

مثلاً شما یه عکس به ChatGPT می‌دین و می‌پرسین «توی این عکس چی می‌بینی؟» و مدل هم شروع می‌کنه درباره‌ی عکس توضیح دادن.

اینجا یه سؤال طبیعی پیش میاد:

آیا یه ابزار جداگانه وجود داره که اول عکس رو به متن تبدیل کنه و بعد اون متن رو بده به LLM؟

مثلاً عکس رو بگیره، تشخیص بده «یه گربه روی صندلی نشسته» و بعد این جمله رو به مدل زبانی بده؟

خیر.

ماجرا این شکلی نیست.

پس عکس چطوری وارد LLM می‌شه؟

برای فهمیدن این موضوع باید یه چیز رو درباره‌ی LLMهای جدید کنار بذاریم: اینکه LLM لزوماً فقط متن می‌گیره.

مدل‌هایی مثل GPT و Gemini در نسخه‌های Multimodal می‌تونن با چند نوع ورودی مختلف کار کنن. یعنی در کنار متن، می‌تونن تصویر و حتی ورودی‌هایی مثل صدا و ویدئو رو هم پردازش کنن.

ولی خب هنوز یه سؤال مهم باقی می‌مونه.

مدل زبانی که با عدد و توکن و embedding کار می‌کنه، دقیقاً با یه عکس چه کار می‌کنه؟

اینجا پای یه بخش دیگه از مدل وسط میاد که معمولاً بهش Vision Encoder یا Image Encoder می‌گن.

Image Encoder چه کار می‌کنه؟

تصویری که شما آپلود می‌کنید، برای کامپیوتر در نهایت یه عالمه عدد مربوط به پیکسل‌هاست.

اما اینکه همین اعداد خام رو بندازیم جلوی LLM و انتظار داشته باشیم بفهمه توی عکس چه خبره، طبیعتاً جواب نمی‌ده.

پس اول تصویر وارد Image Encoder می‌شه.

Image Encoder یه مدل بیناییه که از روی تصویر سعی می‌کنه اطلاعات مهم اون رو استخراج کنه. مثلاً اینکه چه شکل‌هایی توی تصویر وجود دارن، چه الگوهایی دیده می‌شن و بخش‌های مختلف تصویر چه ارتباطی با هم دارن.

معمولاً اینجا با معماری‌هایی مثل Vision Transformer یا ViT سروکار داریم.

خروجی هم دیگه خود عکس نیست. تصویر تبدیل می‌شه به یه سری بردار عددی یا Embedding که اطلاعات تصویر رو در خودشون نگه می‌دارن.

یعنی تا اینجا تقریباً داریم:

عکس → Image Encoder → Embeddingهای تصویری

اما هنوز یه مشکل وجود داره.

مشکل اینجاست که زبان و تصویر یکی نیستن

برای متن هم یه چیزی شبیه همین اتفاق می‌افته.

متنی که شما می‌نویسید اول توسط Tokenizer به توکن‌ها تقسیم می‌شه و بعد این توکن‌ها به embedding تبدیل می‌شن.

پس الان دو طرف داریم:

متن → Tokenizer → Embedding متنی

و

عکس → Image Encoder → Embedding تصویری

ولی این دو embedding الزاماً توی یه فضای مشترک نیستن.

اینجاست که Projection وارد داستان می‌شه.

Projection؛ پلی بین تصویر و متن

Projection رو می‌شه خیلی ساده مثل یه پل در نظر گرفت.

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

در نتیجه اطلاعات تصویر می‌تونه در کنار اطلاعات متنی وارد فرایند پردازش مدل بشه.

یعنی به‌صورت خیلی ساده:

عکس → Vision Encoder → Projection → مدل زبانی

و هم‌زمان:

متن → Tokenizer → مدل زبانی

حالا مدل می‌تونه این دو نوع اطلاعات رو کنار هم داشته باشه.

مثلاً فرض کنید یه عکس از یه خیابون به ChatGPT می‌دید و می‌پرسید:

«چه ماشینی سمت راست تصویر پارک شده؟»

مدل لازم نیست اول عکس رو به یه جمله‌ی ساده مثل «یک خیابون با یک ماشین در آن وجود دارد» تبدیل کنه.

اطلاعات تصویری به شکل embedding وارد سیستم شده و مدل می‌تونه اون رو در کنار سؤال شما پردازش کنه.

به همین دلیله که می‌تونید سؤال‌های خیلی دقیق‌تری هم بپرسید:

«رنگ ماشین سمت راست چیه؟»

«چند نفر توی تصویر هستن؟»

«این نمودار چی رو نشون می‌ده؟»

یا حتی:

«کد داخل این اسکرین‌شات چه مشکلی داره؟»

پس ChatGPT واقعاً عکس رو می‌بینه؟

خب، اینجا باید یه کم مراقب کلمه‌ی «دیدن» باشیم.

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

از طرف دیگه، متن سؤال شما هم به توکن‌ها و embedding تبدیل می‌شه.

مدل در نهایت با ترکیبی از این اطلاعات سروکار داره و بر اساس اون‌ها پاسخ تولید می‌کنه.

پس چیزی که از بیرون شبیه اینه که:

«عکس رو دادم → مدل عکس رو دید → جواب داد»

در پشت صحنه خیلی بیشتر شبیه اینه:

«عکس رو دادم → بخش بینایی اون رو به نمایش عددی تبدیل کرد → این اطلاعات با ورودی متنی ترکیب شد → مدل زبانی بر اساس هر دو پاسخ تولید کرد.»

پس Multimodal دقیقاً یعنی چی؟

اسم Multimodal از همین‌جا میاد.

مودالیتی یا Modality یعنی نوع یا شکل اطلاعات.

متن یه modality محسوب می‌شه، تصویر یه modality دیگه، صدا هم یکی دیگه.

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

و این دقیقاً همون چیزیه که باعث می‌شه بتونید یه عکس، یه سؤال متنی و حتی در بعضی مدل‌ها فایل صوتی یا ویدئو رو به سیستم بدید و انتظار داشته باشید همه‌ی این‌ها رو در کنار هم درک کنه.

یه نکته مهم

البته نباید تصور کنیم که همه‌ی مدل‌های Multimodal دقیقاً همین معماری رو دارن.

GPT، Gemini و مدل‌های دیگه ممکنه از روش‌های متفاوتی برای پردازش تصویر و وصل کردن اطلاعات تصویری به مدل زبانی استفاده کنن.

اما ایده‌ی کلی همینه:

تصویر مستقیماً به یک جمله‌ی متنی تبدیل نمی‌شه؛ اول به یک نمایش عددی تبدیل می‌شه که مدل بتونه باهاش کار کنه.

بنابراین دفعه‌ی بعد که یه عکس رو به ChatGPT می‌دید و ازش درباره‌ی جزئیات اون سؤال می‌کنید، پشت این قابلیت یه «عکس به متن» ساده وجود نداره.

یه مدل بینایی، embedding، projection و در نهایت یه مدل زبانی بزرگ دارن با هم کار می‌کنن تا چیزی که برای ما شبیه «فهمیدن عکس» به نظر می‌رسه، اتفاق بیفته.

یه روز یکی از سرویس‌های داخلیت باید با یه سرویس دیگه حرف بزنه. مثلاً سرویس سفارش باید به سرویس پرداخت بگه «این سفارش رو تسویه کن». اولین راهی که به ذهن خیلی‌ها می‌رسه اینه: یه endpoint باز کن، یه API key هم بذار توش، تمام. مشکل از همینجا شروع میشه، چون «داشتن یه کلید» با «امن بودن ارتباط» فاصله‌ی زیادی داره.

قبل از هر چیز بذار یه چیزی رو روشن کنم: انتخاب پروتکل (REST، GraphQL، gRPC) اصلاً چیزی نیست که امنیت رو تضمین کنه. REST یه انتخاب کاملاً خوبه، ولی خود REST بودن هیچ ربطی به امن بودن نداره. امنیت از جای دیگه‌ای میاد: از اینکه چطور احراز هویت می‌کنی، چطور تصمیم می‌گیری کی به چی دسترسی داره، چطور داده رو رمزنگاری می‌کنی، چطور ورودی‌ها رو validate می‌کنی، و چقدر دو سیستم رو از هم ایزوله نگه می‌داری. این پنج تا با هم امنیت رو می‌سازن، نه انتخاب فرمت پیام.

معماری کلی، قبل از رفتن سراغ جزئیات

یه تصویر کلی از یه معماری معقول این شکلیه: سرویس A از طریق HTTPS به یه API Gateway یا reverse proxy می‌رسه، اونجا احراز هویت، تعیین دسترسی، rate limiting و محدودیت IP اعمال میشه، بعد درخواست به سرویس B واقعی می‌رسه، و در نهایت به دیتابیس. نکته‌ی مهم اینه که هیچ‌کدوم از این لایه‌ها به تنهایی کافی نیستن — این‌ها روی هم دفاع در عمق (defense in depth) رو می‌سازن. هدف طراحی یه سیستم «غیرقابل نفوذ» نیست (چنین چیزی وجود نداره)، هدف اینه که اگه یه لایه شکست خورد، بقیه‌ی سیستم خودکار قربانی نشه.

HTTPS اجباریه، نه اختیاری

این نکته آنقدر بدیهی به نظر می‌رسه که خیلی‌ها ازش رد می‌شن، ولی هنوز هم می‌بینم سرویس‌های داخلی که فقط چون «پشت فایروال هستن» با HTTP ساده کار می‌کنن. فرقی نمی‌کنه ترافیک بین دو تا دیتاسنتر رد بشه یا بین دو تا container توی یه کلاستر — بدون TLS، هر کسی که بین راه بایسته می‌تونه credential ها و داده‌ها رو بخونه. این یعنی همیشه https://api.example.com، هیچ‌وقت http://api.example.com، حتی برای ترافیک کاملاً داخلی.

برای ارتباط سرویس به سرویس، می‌تونی از این هم جلوتر بری و از mutual TLS (mTLS) استفاده کنی. توی TLS معمولی فقط کلاینت مطمئن میشه داره با سرور درست حرف می‌زنه؛ توی mTLS هر دو طرف certificate دارن و همدیگه رو verify می‌کنن. راه‌اندازیش توی Node.js با ماژول https این شکلیه:

const https = require('https');
const fs = require('fs');

const server = https.createServer({
  key: fs.readFileSync('server-key.pem'),
  cert: fs.readFileSync('server-cert.pem'),
  ca: fs.readFileSync('client-ca.pem'),
  requestCert: true,
  rejectUnauthorized: true,
}, (req, res) => {
  res.end('اتصال معتبره');
});

server.listen(443);

نکته‌ی requestCert: true و rejectUnauthorized: true اینجاست که اگه کلاینت certificate معتبر نداشته باشه، اصلاً اجازه‌ی وصل شدن پیدا نمی‌کنه — قبل از اینکه حتی یه خط از کد اپلیکیشنت اجرا بشه. برای API های داخلی حساس، mTLS یکی از قوی‌ترین گزینه‌هاست. مشکلش اینه که مدیریت certificate ها (تمدید، revoke کردن، rotate کردن) خودش یه پروژه‌ی جداست؛ اگه چند تا سرویس داری و مدیریتش برات سخته، ابزارهایی مثل service mesh (Istio، Linkerd) این کار رو خودکار می‌کنن.

از JWT کاربر برای ارتباط سرویس به سرویس استفاده نکن

یه اشتباه رایج اینه که همون JWT ای که برای احراز هویت کاربر نهایی صادر شده رو برای ارتباط بین دو تا سرویس backend هم دوباره‌کاری می‌کنن — یعنی چیزی شبیه Authorization: Bearer <user-jwt> رو بین سرویس‌ها پاس میدن. این کار مرز بین «هویت کاربر» و «هویت سرویس» رو از بین می‌بره و باعث میشه permission های کاربر و سرویس قاطی بشن. به جاش باید یه credential مخصوص machine-to-machine داشته باشی. گزینه‌های خوب اینجا شامل OAuth 2.0 Client Credentials، mTLS، درخواست‌های امضاشده (signed requests)، ترکیب API key و HMAC، و توکن‌های کوتاه‌مدت سرویس‌محور هستن.

برای بیشتر زیرساخت‌های متوسط، ترکیب OAuth 2.0 Client Credentials به‌همراه HTTPS انتخاب معقولیه؛ برای ارتباطات داخلی که واقعاً حساس هستن، mTLS به‌همراه توکن‌های کوتاه‌مدت گزینه‌ی قوی‌تریه.

هر سرویس هویت خودش رو داشته باشه

یه اشتباه دیگه که خیلی رایجه: یه کلید API واحد و master برای همه‌چیز. چیزی شبیه یه متغیر محیطی به اسم MASTER_API_KEY که همه‌ی سرویس‌ها ازش استفاده می‌کنن. مشکل این روش اینه که وقتی یکی از سرویس‌ها compromise بشه، عملاً کل سیستم compromise شده — چون همه از یه کلید استفاده می‌کردن.

راه درست‌تر اینه که هر سرویس یه service account مخصوص خودش داشته باشه، و به هر کدوم فقط همون permission هایی که واقعاً بهش نیاز داره داده بشه. مثلاً اگه سرویس A فقط باید کاربر بسازه و بخونه، نباید اصلاً امکان حذف کاربر یا دسترسی به بخش پرداخت رو داشته باشه:

سرویس A → مجاز به: create_user, read_user, update_access
سرویس A → غیرمجاز به: delete_user, access_payments, access_admin, access_database

به این اصل، least privilege میگن: هر جزء از سیستم فقط دسترسی‌ای رو داشته باشه که برای انجام کارش لازمه، نه بیشتر. این ساده‌ترین و در عین حال مؤثرترین اصلی هست که خیلی از تیم‌ها فراموشش می‌کنن.

احراز هویت با تعیین دسترسی فرق داره

احراز هویت (authentication) به این سؤال جواب میده: «تو کی هستی؟» و تعیین دسترسی (authorization) به این سؤال: «تو اجازه‌ی چه کاری رو داری؟» یه فرض اشتباه رایج اینه که فکر کنیم چون یه request احراز هویت شده، پس قابل اعتماده. این درست نیست. باید هر endpoint جداگانه چک بشه که آیا سرویسی که این درخواست رو فرستاده، مجوز انجام همین عملیات خاص رو داره یا نه. مثلاً POST /users ممکنه نیاز به مجوز user:create داشته باشه، در حالی که DELETE /users/:id ممکنه به یه مجوز کاملاً متفاوت نیاز داشته باشه که خیلی محدودتر بهش داده میشه.

امضای درخواست‌ها با HMAC

برای APIهایی که سطح امنیتی بالاتری می‌خوان، امضای درخواست (request signing) با HMAC یه لایه‌ی اضافه‌ی خیلی خوبیه. ایده اینه که هر دو سرویس یه secret مشترک دارن، و هر request قبل از ارسال با اون secret امضا میشه:

const crypto = require('crypto');

function signRequest(method, path, body, secret) {
  const timestamp = Date.now().toString();
  const payload = method + path + timestamp + JSON.stringify(body);
  const signature = crypto
    .createHmac('sha256', secret)
    .update(payload)
    .digest('hex');
  return { timestamp, signature };
}

این امضا معمولاً توی هدرهایی مثل این ارسال میشه:

X-Client-ID: service-a
X-Timestamp: 1760000000
X-Signature: a3f9c2...

سمت سرور، همین امضا دوباره از روی method، path، timestamp و body محاسبه میشه و با چیزی که تو header اومده مقایسه میشه. اگه یکی وسط راه request رو بگیره و مثلاً ایمیل داخل body رو عوض کنه، امضا دیگه match نمی‌کنه و request رد میشه — بدون اینکه اصلاً لازم باشه محتوای request رمزنگاری بشه؛ همین که تغییرناپذیریش تضمین بشه کافیه.

محافظت در برابر replay attack

فقط امضا کردن request کافی نیست. اگه کسی یه request معتبر و امضاشده رو ضبط کنه و بعداً دوباره همونو بفرسته، امضا هنوز معتبره چون چیزی توش عوض نشده. این همون replay attack هست. راه‌حلش ترکیب سه چیزه: timestamp، یه شناسه‌ی یکتا برای هر request (نان‌س یا request-id)، و امضا:

X-Timestamp: 1760000000
X-Request-ID: 550e8400-e29b-41d4-a716-446655440000
X-Signature: a3f9c2...

منطق سمت سرور این شکلیه: اول چک میشه timestamp توی یه بازه‌ی معقول هست (مثلاً کمتر از پنج دقیقه اختلاف با زمان فعلی سرور)، بعد چک میشه که این request-id قبلاً پردازش نشده (این بخش معمولاً با یه cache سریع مثل Redis پیاده میشه، با یه TTL برابر با همون بازه‌ی زمانی)، و اگه هر دو شرط برقرار بود، امضا verify میشه و در نهایت request-id ذخیره میشه تا دفعه‌ی بعد تکراری تشخیص داده بشه. بدون این مکانیزم، حتی امضای HMAC هم در برابر یه حمله‌ی ساده‌ی «ضبط و پخش دوباره» بی‌دفاعه.

شبکه رو محدود کن، این شاید مهم‌ترین قدمه

اگه سرویس B فقط قراره از طرف سرویس A صدا زده بشه، هیچ دلیلی نداره که اصلاً از اینترنت عمومی در دسترس باشه. این یکی از نکاتی هست که تأثیرش روی امنیت کلی سیستم از خیلی چیزهای دیگه بیشتره، چون هر لایه‌ی امنیتی دیگه‌ای که بذاری (authentication، rate limit، signature) باز هم در معرض حمله قرار می‌گیره اگه شبکه به‌طور عمومی باز باشه.

ابزارهایی که برای این کار به کار میان شامل قوانین فایروال، security group های ابری، شبکه‌ی خصوصی (VPC)، VPN یا WireGuard، IP allowlist، و DNS داخلی هستن. ایده‌آل اینه که ترافیک بین دو سرویس فقط از یه شبکه‌ی خصوصی رد بشه، نه از مسیر عمومی اینترنت که بعد پشت فایروال فیلتر بشه. این دو تا از نظر امنیتی خیلی با هم فرق دارن، حتی اگه نتیجه‌ی نهایی مشابه به نظر برسه.

هیچ‌وقت دسترسی مستقیم دیتابیس نده

یه اشتباه خطرناک که گاهی توی معماری‌های عجله‌ای دیده میشه اینه که یه سرویس بیرونی، مستقیماً credential دیتابیس سرویس دیگه رو داشته باشه. حتی اگه این credential محدود به یه کاربر readonly باشه، این کار لایه‌ی authorization اپلیکیشن رو کاملاً دور می‌زنه. مسیر درست همیشه از طریق API میگذره: سرویس A فقط باید از طریق HTTPS و API عمومی سرویس B باهاش حرف بزنه، و سرویس B خودش تصمیم می‌گیره که این عملیات با توجه به authorization چطور روی دیتابیس اجرا بشه. سرویس A هیچ‌وقت نباید بتونه کاری بیشتر از اونی که API صراحتاً exposed کرده انجام بده.

اعتماد کورکورانه به ورودی، حتی از سرویس داخلی

حتی اگه یه request از یه سرویس authenticated بیاد، بازم باید ورودی‌هاش validate بشن — schema، طول رشته‌ها، فرمت شناسه‌ها، URL ها، اسم فایل‌ها، enum ها، بازه‌ی عددی، و حجم payload. یه نکته‌ی خاص اینجا مربوط به SSRF هست: اگه سرور تو بر اساس یه URL که از سمت کاربر یا سرویس دیگه اومده (مثلاً یه فیلد callback_url) یه request جدید می‌سازه، بدون validate کردن اون آدرس ممکنه یه آسیب‌پذیری SSRF ایجاد بشه که مهاجم بتونه از طریق سرورت به منابع داخلی شبکه دسترسی پیدا کنه که اصلاً نباید بهشون دسترسی داشته باشه.

rate limit فقط برای ترافیک بیرونی نیست

یه سرویس authenticated لزوماً امن نیست. اگه سرویس A به هر دلیلی — یه باگ، یه حلقه‌ی بی‌نهایت، یه retry logic خراب — شروع کنه به بمباران کردن سرویس B، معتبر بودن token یا امضا هیچ کمکی نمی‌کنه. گذاشتن rate limit حتی روی ترافیک کاملاً داخلی، چیزیه که خیلی وقت‌ها دیر بهش فکر می‌کنیم؛ معمولاً بعد از اینکه یه بار یه سرویس داخلی کل کلاستر رو از پا درآورده. منطقی‌ترین کار اینه که برای هر endpoint بر اساس هزینه‌ی محاسباتیش یه سقف جدا تعریف کنی؛ یه request خواندنی ساده و یه عملیات export سنگین طبیعتاً نباید سقف یکسانی داشته باشن.

لاگ کردن، اما نه هر چیزی

وقتی یه چیزی خراب میشه، اولین جایی که سراغش میری لاگ‌هاست. صرفاً لاگ کردن مسیر و متد request (POST /users) کافی نیست؛ چیزهایی که واقعاً کمک‌کننده هستن شامل timestamp، اسم سرویس فرستنده، endpoint، شناسه‌ی یکتای request، نتیجه‌ی عملیات، تصمیم authorization، آدرس IP مبدأ، و latency میشن. نکته‌ی خیلی مهم اینه که هیچ‌وقت secret ها یا credential های حساس رو توی لاگ ننویسی — این خودش یه منبع رایج نشت اطلاعاته که کمتر بهش توجه میشه.

مقایسه‌ی روش‌های ارتباطی

انتخاب پروتکل بین دو سرویس بیشتر به الگوی استفاده بستگی داره تا امنیت، هرچند بعضی گزینه‌ها ذاتاً برای یه سناریوی خاص مناسب‌ترن:

برای ارتباط بین دو پلتفرم مستقل، REST به‌همراه HTTPS و OAuth2 (یا mTLS برای موارد حساس‌تر) یه انتخاب کاملاً محکمه. برای میکروسرویس‌های داخلی که تعداد زیادی درخواست کوچیک و پرتکرار با هم رد و بدل می‌کنن، gRPC یا یه message broker معمولاً منطقی‌تره.

نکته‌ای که در آخر ارزش تکرار کردن داره: هدف طراحی یه API که «هک کردنش غیرممکنه» نیست — چنین چیزی وجود خارجی نداره. هدف اینه که سیستم رو طوری بچینی که compromise شدن یه جزء، خودکار به compromise شدن همه‌چیز منجر نشه. ایزوله کردن شبکه، least privilege، credential های جداگانه برای هر سرویس، محدود کردن دسترسی دیتابیس، و دفاع در عمق، در عمل خیلی بیشتر از انتخاب REST یا GraphQL یا هر پروتکل دیگه‌ای روی امنیت واقعی سیستم تأثیر می‌ذارن.

اگه اسم WebAssembly (یا به اختصار Wasm) رو شنیدی و کنجکاو شدی دقیقاً چیه، جواب کوتاهش اینه: یه فرمت باینری برای اجرای کد با سرعت نزدیک به native، مستقیم تو مرورگر (و جاهای دیگه). ولی این جواب کوتاه نمی‌گه چرا این تکنولوژی این‌قدر مهمه. برای فهمیدنش بهتره از مشکلی شروع کنیم که Wasm حلش می‌کنه.

مشکلی که جاوااسکریپت نمی‌تونست حلش کنه

جاوااسکریپت تنها زبونیه که مرورگرها به‌صورت native اجرا می‌کنن. برای دهه‌ها، اگه می‌خواستی چیزی تو مرورگر اجرا بشه، مجبور بودی یا مستقیم جاوااسکریپت بنویسی، یا زبون دیگه‌ت رو به جاوااسکریپت compile کنی (مثل TypeScript). مشکل اینجاست که جاوااسکریپت یه زبون dynamically-typed و interpreted هست؛ حتی با موتورهای JIT فوق‌پیشرفته‌ای مثل V8، برای کارهای سنگین محاسباتی (پردازش تصویر، فیزیک بازی، رمزنگاری، پردازش صوت و ویدیو) هنوز به سقف عملکرد زبون‌های کامپایل‌شده مثل C++ یا Rust نمی‌رسه.

WebAssembly این محدودیت رو برمی‌داره. به‌جای این‌که مجبور باشی کد C++ یا Rust ت رو به جاوااسکریپت ترجمه کنی (که هم کند و هم ناقصه)، می‌تونی مستقیم به یه فرمت باینری فشرده و بهینه compile‌ش کنی که مرورگر می‌تونه تقریباً به همون سرعت کد native اجراش کنه.

چند تا ویژگی کلیدی

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

Sandboxed و امن: کد Wasm دقیقاً مثل جاوااسکریپت، تو یه محیط ایزوله (sandbox) اجرا می‌شه. نمی‌تونه مستقیم به فایل‌سیستم یا شبکه دسترسی پیدا کنه، مگه از طریق API هایی که خود جاوااسکریپت در اختیارش می‌ذاره. یعنی امنیتش مستقل از این‌که کد اصلی با چه زبونی نوشته شده، حفظ می‌شه.

مستقل از زبان مبدأ: Wasm خودش یه زبون برنامه‌نویسی نیست که مستقیم باهاش کد بنویسی (هرچند می‌شه). بیشتر یه target compilation است؛ یعنی زبون‌هایی مثل C، C++، Rust، Go، و حتی بخش‌هایی از پایتون می‌تونن بهش compile بشن.

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

یه مثال ساده

فرض کن یه تابع محاسباتی سنگین به Rust داری:

#[no_mangle]
pub fn fibonacci(n: u32) -> u64 {
    if n <= 1 {
        return n as u64;
    }
    let mut a = 0u64;
    let mut b = 1u64;
    for _ in 2..=n {
        let temp = a + b;
        a = b;
        b = temp;
    }
    b
}

با ابزاری مثل wasm-pack، این کد به یه فایل .wasm compile می‌شه که می‌شه مستقیم تو جاوااسکریپت import و صداش زد:

import init, { fibonacci } from './pkg/my_wasm_module.js';

async function run() {
    await init();
    console.log(fibonacci(50)); // اجرا با سرعت نزدیک به native
}

run();

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

کجاها واقعاً استفاده می‌شه

ابزارهای سنگین که به مرورگر آوردن: Figma بخش زیادی از موتور رندرش رو با WebAssembly پیاده کرده تا بتونه performance شبیه یه اپلیکیشن دسکتاپ رو تو مرورگر ارائه بده. AutoCAD نسخه‌ی وب خودش رو با پورت کردن دهه‌ها کد C++ به Wasm ساخته.

بازی‌ها و موتورهای گرافیکی: موتورهایی مثل Unity و Unreal Engine امکان export کردن بازی به WebAssembly رو دارن، که یعنی بازی‌های نسبتاً سنگین می‌تونن مستقیم تو مرورگر، بدون نصب هیچ پلاگینی، اجرا بشن.

پردازش تصویر و ویدیو: ابزارهایی مثل ffmpeg.wasm امکان encode/decode کردن ویدیو مستقیم تو مرورگر رو می‌دن، بدون این‌که فایل به سرور آپلود بشه؛ هم سریع‌تره، هم حریم خصوصی کاربر حفظ می‌شه.

اجرای زبون‌های دیگه تو مرورگر: پروژه‌هایی مثل Pyodide، پایتون رو کامل به WebAssembly compile کردن، یعنی می‌تونی کد پایتون واقعی رو مستقیم تو مرورگر، بدون سرور، اجرا کنی.

فراتر از مرورگر: WebAssembly دیگه محدود به مرورگر نیست. با استانداردی به اسم WASI (WebAssembly System Interface)، می‌شه Wasm رو مستقل از مرورگر، رو سرور یا edge computing هم اجرا کرد. کلادفلر Workers و Fastly Compute دقیقاً از همین قابلیت استفاده می‌کنن تا کد رو تو صدها دیتاسنتر مختلف، با startup time خیلی کمتر از یه کانتینر معمولی، اجرا کنن.

چیزی که WebAssembly نیست

یه سوءتفاهم رایج اینه که فکر کنیم Wasm قراره جای جاوااسکریپت رو بگیره. این‌طور نیست؛ Wasm نمی‌تونه مستقیم به DOM دسترسی داشته باشه یا event handler ثبت کنه. برای هر تعامل با صفحه (کلیک، تغییر استایل، دستکاری DOM)، هنوز باید از جاوااسکریپت به‌عنوان واسط استفاده کنی. Wasm بیشتر مکمل جاوااسکریپته تا جایگزینش؛ جاهایی که محاسبات سنگین لازمه، کار رو به Wasm می‌سپاری و بقیه‌ی تعامل با کاربر همچنان با جاوااسکریپت انجام می‌شه.

کِی واقعاً بهش نیاز داری

اگه داری یه اپلیکیشن وب معمولی می‌سازی (فرم، داشبورد، فروشگاه آنلاین)، به احتمال زیاد هیچ‌وقت مستقیم با WebAssembly سروکار پیدا نمی‌کنی؛ جاوااسکریپت (یا فریمورک‌های روش) کاملاً کافیه. Wasm زمانی وارد بازی می‌شه که یه بخش خاص از اپلیکیشنت واقعاً محاسبات سنگین داره (پردازش تصویر/صوت/ویدیو، رمزنگاری، فیزیک، parsing فایل‌های حجیم) و همون بخش داره performance اپ رو محسوس کند می‌کنه. تو اون حالت، می‌تونی فقط همون بخش خاص رو به Rust یا C++ بنویسی و به Wasm compile کنی، بدون این‌که مجبور بشی کل اپلیکیشن رو از جاوااسکریپت خارج کنی.

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

ایده‌ی اصلی

این معماری که اولین بار توسط Alistair Cockburn معرفی شد، می‌گه منطق اصلی کسب‌وکار (business logic یا domain) باید کاملاً مستقل از هر چیز بیرونی باشه؛ چه دیتابیس، چه فریم‌ورک وب، چه API خارجی، چه message queue. این جداسازی از طریق دو مفهوم اصلی اتفاق می‌افته: port و adapter.

Port یه interface است که مشخص می‌کنه domain چه چیزی از دنیای بیرون نیاز داره یا چه چیزی به دنیای بیرون ارائه می‌ده؛ ولی هیچ جزئیات پیاده‌سازی توش نیست. مثلاً یه port می‌تونه بگه «من به یه راه برای پیدا کردن کاربر با ایمیل نیاز دارم»، بدون این‌که بگه این کار با SQL انجام می‌شه یا با یه فایل JSON.

Adapter پیاده‌سازی واقعی اون portه؛ کدی که واقعاً می‌دونه چطور به PostgreSQL وصل بشه، یا چطور یه HTTP request به یه API خارجی بفرسته.

چرا اسمش «هگزاگونال»ه

اسم این معماری از یه شکل شش‌ضلعی میاد که Cockburn برای نشون دادن domain استفاده کرد؛ نه به این خاطر که دقیقاً شش تا port لازمه، بلکه چون شکل شش‌ضلعی جا برای چندین ضلع (port) مختلف می‌ده، بدون این‌که مثل یه مربع محدود به بالا/پایین/چپ/راست باشه. نکته‌ی اصلی این شکل صرفاً بصریه: نشون می‌ده domain می‌تونه از چند جهت مختلف با دنیای بیرون در ارتباط باشه، و هر جهت از طریق یه port مشخص کنترل می‌شه.

دو نوع port: driving و driven

معمولاً port ها به دو دسته تقسیم می‌شن:

Driving port (یا primary/inbound): چیزی که دنیای بیرون رو قادر می‌کنه با domain حرف بزنه. مثلاً یه interface که می‌گه «چطور می‌شه یه سفارش جدید ثبت کرد». یه controller وب یا یه CLI command، از طریق این port به domain دستور می‌ده.

Driven port (یا secondary/outbound): چیزی که domain برای انجام کارش به دنیای بیرون نیاز داره. مثلاً یه interface برای ذخیره‌ی سفارش تو دیتابیس، یا فرستادن ایمیل تأیید.

# Driven port: domain فقط این interface رو می‌شناسه
from abc import ABC, abstractmethod

class OrderRepository(ABC):
    @abstractmethod
    def save(self, order: 'Order') -> None:
        pass

    @abstractmethod
    def find_by_id(self, order_id: str) -> 'Order | None':
        pass


class NotificationSender(ABC):
    @abstractmethod
    def send_order_confirmation(self, order: 'Order') -> None:
        pass

پیاده‌سازی: هسته‌ی domain

هسته‌ی domain فقط به این port ها وابسته‌ست، نه به هیچ پیاده‌سازی خاصی:

class Order:
    def __init__(self, order_id: str, customer_email: str, total: float):
        self.order_id = order_id
        self.customer_email = customer_email
        self.total = total
        self.status = "pending"


class PlaceOrderService:
    def __init__(self, repository: OrderRepository, notifier: NotificationSender):
        self.repository = repository
        self.notifier = notifier

    def place_order(self, order_id: str, customer_email: str, total: float) -> Order:
        if total <= 0:
            raise ValueError("مبلغ سفارش باید مثبت باشه")

        order = Order(order_id, customer_email, total)
        self.repository.save(order)
        self.notifier.send_order_confirmation(order)
        return order

این کلاس PlaceOrderService هیچ ایده‌ای نداره که آیا OrderRepository واقعاً یه دیتابیس PostgreSQL رو صدا می‌زنه یا فقط یه dictionary تو حافظه‌ست. برای همینه که تست کردنش خیلی ساده‌ست:

class InMemoryOrderRepository(OrderRepository):
    def __init__(self):
        self.orders = {}

    def save(self, order):
        self.orders[order.order_id] = order

    def find_by_id(self, order_id):
        return self.orders.get(order_id)


class FakeNotifier(NotificationSender):
    def __init__(self):
        self.sent = []

    def send_order_confirmation(self, order):
        self.sent.append(order)


def test_place_order_saves_and_notifies():
    repo = InMemoryOrderRepository()
    notifier = FakeNotifier()
    service = PlaceOrderService(repo, notifier)

    order = service.place_order("ord_1", "ali@example.com", 150.0)

    assert repo.find_by_id("ord_1") == order
    assert len(notifier.sent) == 1

آداپترهای واقعی

حالا وقتی زمان استفاده‌ی واقعی می‌رسه، همون port ها رو با پیاده‌سازی واقعی adapt می‌کنیم:

import psycopg2

class PostgresOrderRepository(OrderRepository):
    def __init__(self, connection):
        self.connection = connection

    def save(self, order):
        with self.connection.cursor() as cursor:
            cursor.execute(
                "INSERT INTO orders (id, email, total, status) VALUES (%s, %s, %s, %s)",
                (order.order_id, order.customer_email, order.total, order.status)
            )
        self.connection.commit()

    def find_by_id(self, order_id):
        with self.connection.cursor() as cursor:
            cursor.execute("SELECT * FROM orders WHERE id = %s", (order_id,))
            row = cursor.fetchone()
            return Order(*row) if row else None


class EmailNotifier(NotificationSender):
    def __init__(self, smtp_client):
        self.smtp_client = smtp_client

    def send_order_confirmation(self, order):
        self.smtp_client.send(
            to=order.customer_email,
            subject="تأیید سفارش",
            body=f"سفارش {order.order_id} با موفقیت ثبت شد."
        )

خود PlaceOrderService بدون هیچ تغییری، هم با نسخه‌ی تستی کار می‌کنه و هم با نسخه‌ی واقعی؛ فقط adapter ای که موقع wiring کردن اپلیکیشن بهش تزریق می‌شه فرق می‌کنه.

این معماری با Dependency Inversion Principle چه ربطی داره

اگه مقاله‌ی SOLID رو خونده باشی، احتمالاً این الگو برات آشناست؛ معماری هگزاگونال عملاً یه اعمال سیستماتیک از Dependency Inversion Principle تو سطح کل اپلیکیشنه. به‌جای این‌که domain به یه پیاده‌سازی خاص (مثل PostgreSQL) وابسته باشه، هم domain و هم پیاده‌سازی، به یه abstraction مشترک (port) وابسته‌ن. جهت وابستگی همیشه به سمت داخل (به سمت domain) است؛ هیچ‌وقت برعکس.

کجا این معماری واقعاً ارزش داره

این معماری برای اپلیکیشن‌هایی معنی داره که منطق کسب‌وکار پیچیده و قابل‌تغییری دارن، یا احتمال داره زیرساخت‌هاشون (دیتابیس، پیام‌رسان، API های خارجی) تو طول زمان عوض بشه. سیستم‌های مالی، پلتفرم‌های e-commerce با قوانین قیمت‌گذاری پیچیده، یا هر جایی که تیم می‌خواد تست‌های سریع و ایزوله داشته باشه، از این جداسازی سود می‌بره.

در مقابل، برای یه CRUD ساده که فقط داره داده رو از دیتابیس می‌خونه و نمایش می‌ده، بدون منطق کسب‌وکار پیچیده‌ای، اضافه کردن لایه‌های port و adapter فقط پیچیدگی اضافه می‌کنه بدون فایده‌ی متناسب. مثل خیلی از الگوهای معماری دیگه، سؤال درست این نیست که «آیا این الگو خوبه؟»، بلکه اینه که «آیا پیچیدگی پروژه‌م این سرمایه‌گذاری رو توجیه می‌کنه؟»

اگر با Docker کار کرده باشی، احتمالاً صدها بار این دستورات را تایپ کرده‌ای:

docker ps
docker logs my-container
docker restart my-container
docker compose up -d

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

اینجاست که Portainer وارد می‌شود.

Portainer دقیقاً چیست؟

Portainer یک پنل مدیریتی تحت وب برای Docker است که همه کارهای رایج را در یک داشبورد گرافیکی ساده قرار می‌دهد. به‌جای اینکه برای هر کار SSH بزنی و دستور تایپ کنی، از مرورگرت وارد می‌شوی و همه‌چیز را یکجا می‌بینی.

علاوه بر Docker، از Kubernetes، Docker Swarm و Podman هم پشتیبانی می‌کند.

جالب اینجاست که خودِ Portainer هم به‌صورت یک Docker Container اجرا می‌شود.

با Portainer چه کارهایی می‌توانی انجام دهی؟

• مشاهده وضعیت کانتینرهای در حال اجرا
• خواندن لاگ‌های هر سرویس مستقیم از مرورگر
• ورود به Shell کانتینر بدون نیاز به exec -it
• ساخت، حذف و ری‌استارت کانتینرها
• مدیریت Volume ها و Network ها
• اجرای Docker Compose Stack ها
• مدیریت چندین سرور Docker از یک پنل واحد
• مدیریت Image ها و پاک‌سازی فضا

رایگان است یا پولی؟

Portainer Community Edition (CE) کاملاً رایگان و متن‌باز است و برای اکثر توسعه‌دهندگان بیش از کافی است.

اگر می‌خواهی کانتینر اجرا کنی، لاگ بخوانی، Docker Compose مدیریت کنی و اپلیکیشن Deploy کنی، نسخه CE کاملاً کافی است.

نصب روی VPS در کمتر از یک دقیقه

اگر Docker روی سرورت نصب است، با همین دستورات Portainer را راه‌اندازی کن:

docker volume create portainer_data

docker run -d \
  --name portainer \
  --restart unless-stopped \
  -p 127.0.0.1:9443:9443 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v portainer_data:/data \
  portainer/portainer-ce:latest

بعد از اجرا از مرورگر وارد شو:

https://YOUR_SERVER_IP:9443

نکته امنیتی: هرگز Portainer را مستقیم روی پورت عمومی اجرا نکن. حتماً پشت Nginx با HTTPS قرار بده و پورت ۹۴۴۳ را از Firewall مسدود کن.

برای چه کسانی مناسب است؟

• توسعه‌دهندگانی که VPS یا سرور شخصی دارند
• کسانی که سرویس‌هایی مثل PostgreSQL، Redis، MinIO یا Grafana را Self-host می‌کنند
• تازه‌کارهایی که دارند Docker یاد می‌گیرند و می‌خواهند وضعیت کانتینرها را بصری ببینند
• فریلنسرها و تیم‌های کوچکی که باید چند پروژه روی یک سرور مدیریت کنند

Portainer جایگزین CLI می‌شود؟

نه، و نباید باشد. Portainer یک ابزار مکمل است، نه جایگزین. برای مدیریت روزمره و مانیتورینگ عالی است، اما برای کارهای پیشرفته‌تر مثل دیباگ مشکلات شبکه، نوشتن Compose فایل‌های پیچیده یا Scripting، همچنان به CLI نیاز داری.

توصیه: هر دو را یاد بگیر. CLI برای تسلط واقعی ضروری است، Portainer برای مدیریت راحت‌تر روزانه.

جمع‌بندی

Portainer یک ابزار رایگان، سریع و کاربرپسند برای مدیریت Docker است. اگر سرور یا VPS داری، نصب Portainer یکی از اولین کارهایی است که باید انجام دهی. در کمتر از یک دقیقه نصب می‌شود و از همان لحظه مدیریت کانتینرهایت را متحول می‌کند.

اگه تا حالا تو ترمینال یه فایل دانلود کردی یا یه API رو تست کردی، احتمالاً با هر دوی این ابزارها برخورد داشتی. هر دو کارشون رفتن سراغ یه URL و گرفتن داده از اونه، و تو خیلی از موارد ساده، هر کدوم رو که استفاده کنی فرقی نمی‌کنه. ولی وقتی پای موارد پیچیده‌تر وسط بیاد، این دو تا فلسفه‌ی کاملاً متفاوتی دارن که دونستنش از انتخاب اشتباه و کلنجار رفتن با فلگ‌های اضافه جلوگیری می‌کنه.

فلسفه‌ی طراحی این دو فرق داره

wget از اول برای یه کار مشخص ساخته شده: دانلود فایل، به‌خصوص دانلودهای بزرگ و طولانی که ممکنه قطع بشن. به همین خاطر ویژگی‌هایی مثل ادامه دادن دانلود ناقص، دانلود recursive (گرفتن یه سایت کامل با تمام لینک‌هاش)، و کار کردن بدون نیاز به یه session تعاملی جزو ذات wget هستن.

curl از اول یه چیز دیگه بود: یه ابزار برای انتقال داده با هر پروتکلی که می‌تونی تصورش کنی (HTTP، HTTPS، FTP، SFTP، حتی SMTP و IMAP)، با تمرکز روی کنترل کامل روی request. برای همین امروز curl تبدیل شده به ابزار پیش‌فرض برای تست کردن API ها، چون بهت اجازه می‌ده هر جزئیات یه HTTP request رو (method، header، body، auth) دقیق کنترل کنی.

دانلود ساده‌ی یه فایل

# wget
wget https://example.com/file.zip

# curl (باید صراحتاً بگی خروجی رو تو یه فایل ذخیره کنه)
curl -O https://example.com/file.zip

اینجا فرق مهمی هست: wget به‌صورت پیش‌فرض خروجی رو تو یه فایل ذخیره می‌کنه، ولی curl به‌صورت پیش‌فرض محتوا رو مستقیم تو ترمینال چاپ می‌کنه، مگه این‌که با فلگ -O (ذخیره با همون اسم فایل تو URL) یا -o filename (ذخیره با اسم دلخواه) بهش بگی که فایل رو ذخیره کنه. این تفاوت دقیقاً از همون فلسفه‌ی طراحی میاد؛ wget برای دانلود ساخته شده، curl برای انتقال و بازی با داده.

کار با API و HTTP request های پیچیده

اینجا جاییه که curl واقعاً می‌درخشه. فرض کن می‌خوای یه POST request با JSON body و یه auth header بفرستی:

curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -d '{"name": "Ali", "email": "ali@example.com"}'

با curl می‌تونی method رو با -X مشخص کنی، هر تعداد header دلخواه با -H اضافه کنی، body رو با -d بفرستی، و حتی response headers رو با -i ببینی. wget هم می‌تونه بعضی از این کارها رو انجام بده (مثلاً --header و --post-data)، ولی سینتکسش برای این‌جور کارها اصلاً طراحی نشده و خیلی زود دست‌وپاگیر می‌شه. برای همین تقریباً هیچ‌وقت نمی‌بینی کسی wget رو برای تست API پیشنهاد بده.

دانلود recursive و آینه کردن یه سایت

اینجا برعکس می‌شه. اگه بخوای یه سایت کامل یا یه پوشه از فایل‌ها رو recursive دانلود کنی:

wget --recursive --level=2 --no-parent https://example.com/docs/

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

ادامه دادن دانلود قطع‌شده

هر دو ابزار این قابلیت رو دارن، ولی رفتار پیش‌فرضشون فرق داره:

# wget: با -c دانلود ناقص رو از همون‌جا ادامه می‌ده
wget -c https://example.com/large-file.iso

# curl: با -C - همین کار رو می‌کنه
curl -C - -O https://example.com/large-file.iso

هر دو این کار رو با چک کردن سایز فایل موجود و فرستادن یه Range header انجام می‌دن، ولی wget این رفتار رو ساده‌تر و با کانتکست دانلود فایل طراحی کرده (مثلاً retry خودکار در صورت قطع شدن اتصال با --tries).

جمع‌بندی: کدوم رو کِی استفاده کنیم

اگه داری یه API رو تست می‌کنی، یه request سفارشی با header و body خاص می‌فرستی، یا می‌خوای response رو دقیق بررسی کنی، curl انتخاب درسته؛ کنترلی که رو جزئیات HTTP بهت می‌ده رقیب نداره.

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

نکته‌ی آخر این‌که تو خیلی از distro های لینوکس امروز، هر دو ابزار از قبل نصب هستن، پس هزینه‌ی نگه‌داشتن هر دو تو ابزارهای روزمره‌ت تقریباً صفره؛ لازم نیست حتماً یکیشون رو انتخاب کنی و کنار بذاری.

یه حقیقت ساده از همون اول: اگه شش ماه پیش لینوکس نصب کردی روی یه ماشین معمولی، احتمالاً الان روی Wayland هستی — حتی اگه ندونی. Fedora 40+، Ubuntu 24.04+، Arch، GNOME 49، و KDE Plasma 6 همه به‌صورت پیش‌فرض به Wayland رفتن. این دیگه یه بحث «آینده‌ی Linux» نیست. این وضعیت الان هست.

سوال واقعی اینه که چرا این اتفاق افتاد، چه چیزی هنوز نشکسته، و چه کسی نباید عجله کنه.

X11 چه مشکلی داشت

X11 در ۱۹۸۴ طراحی شد — و معماریش دقیقاً همون‌قدر که از اون زمان انتظار داری، قدیمیه.

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

اوایل ۲۰۲۵ سه آسیب‌پذیری بحرانی (CVE-2025-62229، CVE-2025-62230، CVE-2025-62231) توی X.Org پیدا شد — باگ‌هایی که بعضی‌هاشون از بیست سال پیش توی کد بودن. اینا isolated incident نبودن؛ نشونه‌ی یه codebase چهل‌ساله‌ان که maintenance-only شده. هیچ توسعه‌ی فعالی روی X.Org اتفاق نمی‌افته — فقط security patch.

مشکل معماری دیگه‌ای هم وجود داره: رندرینگ کند. هر frame باید از برنامه به X server و بعد به compositor بره — این double-buffering بی‌دلیل توی hardware مدرن کاملاً غیرضروریه و توی بعضی حالت‌ها باعث tearing می‌شه.

Wayland چطور متفاوته

Wayland یه «سرور» مرکزی نداره. هر اپلیکیشن مستقیم به یه off-screen buffer رندر می‌کنه، و compositor مستقیم با driver کار می‌کنه تا frame نهایی رو به مانیتور بفرسته. واسطه نیست.

نتیجه‌های عملی این معماری:

امنیت: هر اپلیکیشن فقط ورودی‌های خودش رو می‌بینه. keylogger نوشتن روی Wayland از طریق protocol عملاً غیرممکنه. البته XWayland — که X11 appها رو روی Wayland اجرا می‌کنه — همچنان این ایزوله‌سازی رو نداره، ولی native Wayland appها ندارن.

رندر تمیزتر: چون compositor مستقیم با GPU کار می‌کنه، screen tearing توی حالت‌های معمولی اتفاق نمی‌افته. توی سیستم‌های با refresh rate بالا یا HiDPI این فرق محسوسه.

نه یه display server، بلکه یه protocol: این نکته مهمه. Wayland خودش یه نرم‌افزار نیست — یه spec هست. GNOME با Mutter، KDE با KWin، Hyprland، Sway — هر کدوم پیاده‌سازی جدا دارن. این یعنی تجربه‌ی Wayland از یه compositor به compositor دیگه می‌تونه فرق کنه.

وضعیت واقعی ۲۰۲۶

اگه از GNOME یا KDE Plasma استفاده می‌کنی، Wayland الان default هست و برای اکثر کارها بدون دردسر کار می‌کنه. طبق یه survey از ۳۹۲۳ کاربر Arch در ژانویه ۲۰۲۵، ۸۰ درصد روی Wayland بودن. GNOME از نسخه‌ی ۴۹ (۲۰۲۵) X11 session رو کاملاً حذف کرده. KDE Plasma 6.8 که اواخر ۲۰۲۶ یا ۲۰۲۷ میاد هم همین کار رو خواهد کرد.

NVIDIA که قبلاً مشکل‌سازترین قسمت بود، با driver series 495+ وضعش خیلی بهتر شده. اکثر کاربران NVIDIA الان می‌تونن Wayland رو بدون دردسر زیادی اجرا کنن — ولی اگه GPU قدیمیه (GTX 1000 series و قدیمی‌تر)، ممکنه همچنان مشکل داشته باشی.

چه کسی نباید عجله کنه

Wayland برای همه مناسب نیست — حداقل نه الان:

اگه از SSH X forwarding (ssh -X یا ssh -Y) برای باز کردن GUI برنامه‌های remote استفاده می‌کنی، Wayland این رو natively پشتیبانی نمی‌کنه. باید از راه‌حل‌های دیگه مثل RDP یا VNC استفاده کنی.

اگه از ابزارهای automation روی desktop استفاده می‌کنی — xdotool، wmctrl، AutoKey — اینا روی Wayland کار نمی‌کنن چون Wayland به appها اجازه نمی‌ده ورودی سیستمیک simulate کنن.

اگه از window manager های سبک مثل i3، openbox، یا fluxbox استفاده می‌کنی، نسخه‌های Wayland بعضی‌هاشون بالغ نیستن. Sway جایگزین i3 روی Wayland هست، ولی feature parity کامل نداره.

اگه از VNC برای remote desktop استفاده می‌کنی، X11 network transparency همچنان این use case رو راحت‌تر می‌کنه.

setup چقدر سخته

برای کاربر معمولی با GNOME یا KDE، عملاً هیچ setup ای لازم نیست — چون اگه لینوکس مدرن نصب کردی، احتمالاً از قبل روی Wayland هستی. چک کردنش ساده‌ست:

echo $XDG_SESSION_TYPE   # باید "wayland" برگردونه

اگه X11 هست و می‌خوای Wayland امتحان کنی، توی login screen (GDM یا SDDM) می‌تونی session نوع رو عوض کنی — بدون نیاز به نصب چیزی. بعد از login کافیه echo $XDG_SESSION_TYPE بزنی و ببینی.

اگه بخوای برگردی، همون راه رو از login screen برعکس کن.

X11 appها چی می‌شن

اکثر X11 appها روی Wayland از طریق XWayland کار می‌کنن — یه X server که به‌عنوان یه Wayland client اجرا می‌شه. در عمل، بیشتر برنامه‌ها بدون تغییر کار می‌کنن. محدودیت‌ها از همون security model میان: appهایی که global pointer position یا synthetic input نیاز دارن زیر XWayland هم مشکل دارن.

جمع‌بندی واقع‌بینانه

Wayland برای اکثر کاربران لینوکس دسکتاپ الان انتخاب بهتریه — نه چون X11 خراب شده، بلکه چون Wayland معماری تمیزتر، امنیت ساختاری بهتر، و پشتیبانی از display مدرن (HiDPI، variable refresh rate) رو از اساس حل می‌کنه.

ولی اگه workflow ات به X forwarding، GUI automation، یا window manager هایی که Wayland equivalent ندارن وابسته‌ست، X11 هنوز گزینه‌ی درست‌تره. و این انتخاب هیچ ایرادی نداره — هر دو همزمان در دسترسند و X11 حداقل تا ۲۰۲۸ patch خواهد خورد.

اگه اسم WebAssembly (یا به اختصار Wasm) رو شنیدی و کنجکاو شدی دقیقاً چیه، جواب کوتاهش اینه: یه فرمت باینری برای اجرای کد با سرعت نزدیک به native، مستقیم تو مرورگر (و جاهای دیگه). ولی این جواب کوتاه نمی‌گه چرا این تکنولوژی این‌قدر مهمه. برای فهمیدنش بهتره از مشکلی شروع کنیم که Wasm حلش می‌کنه.

مشکلی که جاوااسکریپت نمی‌تونست حلش کنه

جاوااسکریپت تنها زبونیه که مرورگرها به‌صورت native اجرا می‌کنن. برای دهه‌ها، اگه می‌خواستی چیزی تو مرورگر اجرا بشه، مجبور بودی یا مستقیم جاوااسکریپت بنویسی، یا زبون دیگه‌ت رو به جاوااسکریپت compile کنی (مثل TypeScript). مشکل اینجاست که جاوااسکریپت یه زبون dynamically-typed و interpreted هست؛ حتی با موتورهای JIT فوق‌پیشرفته‌ای مثل V8، برای کارهای سنگین محاسباتی (پردازش تصویر، فیزیک بازی، رمزنگاری، پردازش صوت و ویدیو) هنوز به سقف عملکرد زبون‌های کامپایل‌شده مثل C++ یا Rust نمی‌رسه.

WebAssembly این محدودیت رو برمی‌داره. به‌جای این‌که مجبور باشی کد C++ یا Rust ت رو به جاوااسکریپت ترجمه کنی (که هم کند و هم ناقصه)، می‌تونی مستقیم به یه فرمت باینری فشرده و بهینه compile‌ش کنی که مرورگر می‌تونه تقریباً به همون سرعت کد native اجراش کنه.

چند تا ویژگی کلیدی

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

Sandboxed و امن: کد Wasm دقیقاً مثل جاوااسکریپت، تو یه محیط ایزوله (sandbox) اجرا می‌شه. نمی‌تونه مستقیم به فایل‌سیستم یا شبکه دسترسی پیدا کنه، مگه از طریق API هایی که خود جاوااسکریپت در اختیارش می‌ذاره. یعنی امنیتش مستقل از این‌که کد اصلی با چه زبونی نوشته شده، حفظ می‌شه.

مستقل از زبان مبدأ: Wasm خودش یه زبون برنامه‌نویسی نیست که مستقیم باهاش کد بنویسی (هرچند می‌شه). بیشتر یه target compilation است؛ یعنی زبون‌هایی مثل C، C++، Rust، Go، و حتی بخش‌هایی از پایتون می‌تونن بهش compile بشن.

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

یه مثال ساده

فرض کن یه تابع محاسباتی سنگین به Rust داری:

#[no_mangle]
pub fn fibonacci(n: u32) -> u64 {
    if n <= 1 {
        return n as u64;
    }
    let mut a = 0u64;
    let mut b = 1u64;
    for _ in 2..=n {
        let temp = a + b;
        a = b;
        b = temp;
    }
    b
}

با ابزاری مثل wasm-pack، این کد به یه فایل .wasm compile می‌شه که می‌شه مستقیم تو جاوااسکریپت import و صداش زد:

import init, { fibonacci } from './pkg/my_wasm_module.js';

async function run() {
    await init();
    console.log(fibonacci(50)); // اجرا با سرعت نزدیک به native
}

run();

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

کجاها واقعاً استفاده می‌شه

ابزارهای سنگین که به مرورگر آوردن: Figma بخش زیادی از موتور رندرش رو با WebAssembly پیاده کرده تا بتونه performance شبیه یه اپلیکیشن دسکتاپ رو تو مرورگر ارائه بده. AutoCAD نسخه‌ی وب خودش رو با پورت کردن دهه‌ها کد C++ به Wasm ساخته.

بازی‌ها و موتورهای گرافیکی: موتورهایی مثل Unity و Unreal Engine امکان export کردن بازی به WebAssembly رو دارن، که یعنی بازی‌های نسبتاً سنگین می‌تونن مستقیم تو مرورگر، بدون نصب هیچ پلاگینی، اجرا بشن.

پردازش تصویر و ویدیو: ابزارهایی مثل ffmpeg.wasm امکان encode/decode کردن ویدیو مستقیم تو مرورگر رو می‌دن، بدون این‌که فایل به سرور آپلود بشه؛ هم سریع‌تره، هم حریم خصوصی کاربر حفظ می‌شه.

اجرای زبون‌های دیگه تو مرورگر: پروژه‌هایی مثل Pyodide، پایتون رو کامل به WebAssembly compile کردن، یعنی می‌تونی کد پایتون واقعی رو مستقیم تو مرورگر، بدون سرور، اجرا کنی.

فراتر از مرورگر: WebAssembly دیگه محدود به مرورگر نیست. با استانداردی به اسم WASI (WebAssembly System Interface)، می‌شه Wasm رو مستقل از مرورگر، رو سرور یا edge computing هم اجرا کرد. کلادفلر Workers و Fastly Compute دقیقاً از همین قابلیت استفاده می‌کنن تا کد رو تو صدها دیتاسنتر مختلف، با startup time خیلی کمتر از یه کانتینر معمولی، اجرا کنن.

چیزی که WebAssembly نیست

یه سوءتفاهم رایج اینه که فکر کنیم Wasm قراره جای جاوااسکریپت رو بگیره. این‌طور نیست؛ Wasm نمی‌تونه مستقیم به DOM دسترسی داشته باشه یا event handler ثبت کنه. برای هر تعامل با صفحه (کلیک، تغییر استایل، دستکاری DOM)، هنوز باید از جاوااسکریپت به‌عنوان واسط استفاده کنی. Wasm بیشتر مکمل جاوااسکریپته تا جایگزینش؛ جاهایی که محاسبات سنگین لازمه، کار رو به Wasm می‌سپاری و بقیه‌ی تعامل با کاربر همچنان با جاوااسکریپت انجام می‌شه.

کِی واقعاً بهش نیاز داری

اگه داری یه اپلیکیشن وب معمولی می‌سازی (فرم، داشبورد، فروشگاه آنلاین)، به احتمال زیاد هیچ‌وقت مستقیم با WebAssembly سروکار پیدا نمی‌کنی؛ جاوااسکریپت (یا فریمورک‌های روش) کاملاً کافیه. Wasm زمانی وارد بازی می‌شه که یه بخش خاص از اپلیکیشنت واقعاً محاسبات سنگین داره (پردازش تصویر/صوت/ویدیو، رمزنگاری، فیزیک، parsing فایل‌های حجیم) و همون بخش داره performance اپ رو محسوس کند می‌کنه. تو اون حالت، می‌تونی فقط همون بخش خاص رو به Rust یا C++ بنویسی و به Wasm compile کنی، بدون این‌که مجبور بشی کل اپلیکیشن رو از جاوااسکریپت خارج کنی.

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

چرا Valkey اصلاً به وجود اومد

مارس ۲۰۲۴، شرکت Redis Ltd. اعلام کرد که نسخه‌های بعدی Redis دیگه از لایسنس متن‌باز BSD استفاده نمی‌کنن و به‌جاش زیر لایسنس‌های Source Available (مثل RSALv2 و SSPLv1) منتشر می‌شن. این تغییر یعنی شرکت‌هایی که می‌خواستن Redis رو به‌عنوان یه سرویس ارائه بدن (مثل کلود پرووایدرها)، دیگه اجازه‌ی این کار رو بدون توافق جداگانه با Redis Ltd. نداشتن.

این تصمیم واکنش شدیدی تو کامیونیتی اوپن‌سورس ایجاد کرد. چند روز بعد، لینوکس فاندیشن به همراه چند تا شرکت بزرگ (از جمله AWS، Google Cloud، Oracle، Ericsson و چند تا دیگه) پروژه‌ی Valkey رو راه انداختن؛ یه fork از آخرین نسخه‌ی BSD-licensed Redis (نسخه‌ی ۷.۲.۴) که زیر همون لایسنس متن‌باز BSD قدیمی باقی می‌مونه و توسعه‌اش کاملاً community-driven پیش می‌ره.

از نظر فنی چقدر فرق دارن

نکته‌ی مهم اینه که چون Valkey از یه commit مشخص از Redis فورک شده، تا مدت‌ها تقریباً کد یکسانی داشتن؛ همون دستورات، همون ساختار داده (string، hash، list، set، sorted set)، و همون پروتکل RESP. یعنی اگه یه اپلیکیشن با Redis کار می‌کرد، تغییر به Valkey تو خیلی از موارد فقط با عوض کردن آدرس سرور ممکن بود، بدون تغییر تو کد.

ولی از اون موقع، هر دو پروژه مسیر مستقل خودشون رو رفتن. Valkey ویژگی‌هایی مثل بهبود عملکرد چندنخی (multi-threading بهتر برای بعضی عملیات)، کاهش مصرف حافظه، و چند تا دستور جدید اضافه کرده که مستقیماً از Redis نمیان. از طرف دیگه، Redis Ltd. هم بعداً یه تغییر جهت دیگه داد و اعلام کرد که از نسخه‌ی ۸ به بعد، Redis دوباره زیر یه لایسنس متن‌باز (AGPLv3) منتشر می‌شه؛ هرچند AGPL هم شرایط خاص خودش رو داره و دقیقاً همون آزادی BSD رو نمی‌ده.

چرا این تفاوت لایسنس واقعاً مهمه

برای خیلی از تیم‌ها، این موضوع صرفاً یه بحث حقوقی انتزاعی نیست. لایسنس‌های Source Available که Redis Ltd. تو یه بازه استفاده کرد، محدودیت‌هایی رو برای شرکت‌هایی که می‌خوان از Redis به‌عنوان بخشی از یه سرویس commercial استفاده کنن ایجاد می‌کنه. حتی با برگشت Redis به AGPL، بعضی سازمان‌ها (به‌خصوص اون‌هایی که سیاست‌های سخت‌گیرانه‌ای درباره‌ی لایسنس‌های copyleft قوی دارن) ترجیح می‌دن سراغ چیزی برن که از اول زیر BSD مونده، بدون هیچ تغییر مسیری تو تاریخچه‌ش.

همین عدم قطعیت باعث شده خیلی از توزیع‌های لینوکس بزرگ (مثل Debian و Fedora) و کلود پرووایدرهای بزرگ (AWS با Amazon ElastiCache و Google Cloud با Memorystor) به سمت پشتیبانی از Valkey حرکت کنن یا حداقل گزینه‌ی Valkey رو کنار Redis ارائه بدن.

کدوم رو باید انتخاب کنی

اگه یه پروژه‌ی جدید رو از صفر شروع می‌کنی و لایسنس متن‌باز کاملاً آزاد (BSD) برات اهمیت داره، یا می‌خوای مطمئن باشی که هیچ تغییر لایسنسی تو آینده گریبانت رو نمی‌گیره، Valkey انتخاب منطقی‌تریه؛ مخصوصاً که پشتوانه‌ی چند تا از بزرگ‌ترین شرکت‌های زیرساخت دنیا رو داره و توسعه‌ش هم فعاله.

اگه از قبل با Redis کار می‌کنی و به ابزارها، افزونه‌ها یا سرویس‌های خاصی که مستقیم از Redis Ltd. میان وابسته‌ای (مثل Redis Enterprise یا بعضی ماژول‌های اختصاصی)، یا اصلاً لایسنس براتون مسئله‌ی حادی نیست، ادامه دادن با Redis همچنان گزینه‌ی معتبریه؛ خصوصاً که با AGPL نسخه‌ی ۸، دوباره به یه مسیر متن‌باز برگشته.

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

فرض کن یک 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

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

// pseudo-code ساده برای fixed window
const requests = {}; // { userId: { count, windowStart } }

function isAllowed(userId, limit = 100, windowMs = 60000) {
  const now = Date.now();
  const entry = requests[userId];

  if (!entry || now - entry.windowStart > windowMs) {
    requests[userId] = { count: 1, windowStart: now };
    return true;
  }

  if (entry.count >= limit) return false;
  entry.count++;
  return true;
}

مشکل این روش یک نکته‌ی ظریفه: چون بازه‌ها ثابت و جدا از همن، یک کلاینت میتونه دقیقاً لحظه‌ی آخر یک بازه ۱۰۰ درخواست بفرسته و دقیقاً لحظه‌ی اول بازه‌ی بعدی، ۱۰۰ درخواست دیگه — یعنی توی یک بازه‌ی دو ثانیه‌ای واقعی، ۲۰۰ درخواست رد شده، درحالی‌که سقف روی کاغذ ۱۰۰ در دقیقه بود. به این پدیده burst at boundary میگن.

Sliding Window

این روش با نگه‌داشتن timestamp دقیق هر درخواست (یا یک تقریب وزن‌دار از دو بازه‌ی متوالی)، مشکل burst مرزی رو حل میکنه. دقیق‌تره ولی حافظه و محاسبات بیشتری میخواد، چون باید یا timestamp های تک‌تک درخواست‌ها رو نگه داری، یا یک فرمول ترکیبی حساب کنی.

Token Bucket

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

class TokenBucket {
  constructor(capacity, refillRatePerSec) {
    this.capacity = capacity;
    this.tokens = capacity;
    this.refillRate = refillRatePerSec;
    this.lastRefill = Date.now();
  }

  tryConsume() {
    this._refill();
    if (this.tokens < 1) return false;
    this.tokens -= 1;
    return true;
  }

  _refill() {
    const now = Date.now();
    const elapsedSec = (now - this.lastRefill) / 1000;
    this.tokens = Math.min(this.capacity, this.tokens + elapsedSec * this.refillRate);
    this.lastRefill = now;
  }
}

Leaky Bucket

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

کجا پیاده‌سازیش کنیم

rate limiting رو میشه در چند لایه پیاده کرد. توی سطح Nginx یا یک reverse proxy، با ماژول limit_req میشه بدون تغییر کد اپلیکیشن، محدودیت گذاشت:

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

server {
    location /api/ {
        limit_req zone=api_limit burst=20 nodelay;
        proxy_pass http://backend;
    }
}

توی سطح اپلیکیشن، معمولاً از Redis برای نگه‌داشتن شمارنده‌ها استفاده میشه، چون Redis سریع و atomic عمل میکنه و اگه چند instance از سرور اپلیکیشن داشته باشی، همه بتونن یک شمارنده‌ی مشترک رو ببینن (که با یک شمارنده‌ی in-memory جدا روی هر instance، امکانش نیست).

توی سطح API Gateway (مثل Kong، AWS API Gateway، یا Cloudflare)، rate limiting معمولاً به‌صورت آماده و قابل‌تنظیم از طریق پنل مدیریت وجود داره، بدون نیاز به نوشتن کد.

پاسخ درست به کلاینت رد شده

وقتی یک درخواست به‌خاطر rate limit رد میشه، باید کد وضعیت HTTP استاندارد 429 Too Many Requests رو برگردونی، و بهتره هدر Retry-After رو هم اضافه کنی تا کلاینت بدونه دقیقاً چند ثانیه دیگه باید صبر کنه قبل از تلاش مجدد. این جزئیات کوچیک، تفاوت بین یک API قابل‌اعتماد و یکی که کلاینت‌هاش رو گیج میکنه رو میسازه.

چطوری بهتره استفاده بشه ؟

Rate limiting را می‌توان در چند لایه مختلف پیاده‌سازی کرد؛ از لایه زیرساخت مثل Nginx و API Gateway گرفته تا داخل خود اپلیکیشن. انتخاب محل مناسب بستگی دارد به اینکه هدف اصلی، محافظت از منابع سیستم است یا کنترل رفتار کاربران و قوانین کسب‌وکار.

Rate Limiting در Nginx / Reverse Proxy

Nginx در لایه ورودی سیستم قرار می‌گیرد و قبل از رسیدن درخواست به اپلیکیشن تصمیم می‌گیرد که درخواست اجازه عبور دارد یا نه. مزیت اصلی این روش این است که درخواست‌های اضافی اصلاً وارد برنامه نمی‌شوند و منابعی مثل CPU، حافظه و اتصال‌های دیتابیس مصرف نمی‌شوند.

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

مزایا:

• عملکرد بسیار بالا

• کاهش فشار روی اپلیکیشن

• عدم نیاز به تغییر کد برنامه

محدودیت اصلی آن این است که معمولاً فقط به اطلاعاتی مثل IP و Header دسترسی دارد و نمی‌تواند تفاوت بین کاربران، پلن‌ها یا سطح دسترسی آن‌ها را تشخیص دهد.

مثلاً نمی‌تواند به‌تنهایی تصمیم بگیرد که یک کاربر رایگان فقط ۱۰۰ درخواست در دقیقه داشته باشد و یک کاربر حرفه‌ای ۱۰۰۰۰ درخواست.

Rate Limiting در Middleware اپلیکیشن

در این روش محدودیت داخل خود برنامه اعمال می‌شود. چون اپلیکیشن اطلاعات بیشتری درباره کاربر دارد، می‌تواند قوانین دقیق‌تری بر اساس User ID، API Key، نقش کاربر یا نوع اشتراک اعمال کند.

برای مثال، یک سرویس هوش مصنوعی می‌تواند برای کاربران رایگان محدودیت ۱۰ درخواست در روز و برای کاربران پولی محدودیت ۱۰۰۰ درخواست در روز قرار دهد.

مزایا:

• دسترسی به اطلاعات کامل کاربر

• مناسب برای قوانین کسب‌وکار

• انعطاف‌پذیری بالا

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

برای مثال اگر یک کاربر ۱۰۰ درخواست ارسال کند و Load Balancer آن را بین دو سرور تقسیم کند، هر سرور ممکن است فقط ۵۰ درخواست ببیند و محدودیت به‌درستی اعمال نشود.

به همین دلیل معمولاً از Redis یا یک ذخیره‌ساز مشترک برای نگهداری وضعیت rate limit استفاده می‌شود.

Rate Limiting در API Gateway

API Gateway یک لایه مدیریتی بین کلاینت و سرویس‌های مختلف قرار می‌گیرد و معمولاً برای معماری‌های بزرگ و چندسرویسی استفاده می‌شود.

این لایه می‌تواند محدودیت‌های مشترکی برای تمام APIها اعمال کند، API Key مدیریت کند، quota تعریف کند و سیاست‌های امنیتی را به‌صورت متمرکز اجرا کند.

مزایا:

• مناسب برای Microserviceها

• مدیریت متمرکز APIها

• پشتیبانی از API Key و quota

در مقابل، پیچیدگی و هزینه بیشتری نسبت به Nginx یا middleware ساده دارد و برای پروژه‌های کوچک ممکن است بیش از نیاز باشد.

بهترین رویکرد: ترکیبی از چند لایه

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

یک معماری رایج:

Client

   |
   v

Cloudflare / WAF

   |
   v

Nginx
(IP Rate Limit)

   |
   v

Application
(User/API Key Limit)

   |
   v

Redis
(Shared Counter)

   |
   v

Database

در این معماری:

• Nginx جلوی فشار غیرعادی روی زیرساخت را می‌گیرد.

• Middleware اپلیکیشن محدودیت‌های مربوط به کاربران و منطق کسب‌وکار را اجرا می‌کند.

• Redis وضعیت rate limit را بین چند سرور هماهنگ نگه می‌دارد.

• API Gateway در سیستم‌های بزرگ مدیریت متمرکز APIها را انجام می‌دهد.

مثال:

برای یک وب‌سایت بلاگی متوسط، یک نقطه شروع منطقی می‌تواند این باشد:

• محدودیت عمومی در Nginx:
  حدود 50 تا 100 درخواست در ثانیه برای هر IP
• محدودیت در سطح کاربر:
  حدود 1000 تا 3000 درخواست در ساعت که مثلا از ۱۰۰۰ تا برای مهمان و ۳۰۰۰ برای بالاترین سطح دسترسی قبل از ادمین
• endpointهای حساس:
  بین 3 تا 10 درخواست در دقیقه

اما این اعداد قطعی نیستند. یک وب‌سایت خبری با میلیون‌ها بازدید روزانه، یک وبلاگ شخصی و یک SaaS با API عمومی، نیازهای کاملاً متفاوتی دارند.

عدد صحیح زمانی مشخص می‌شود که رفتار واقعی کاربران، میانگین درخواست‌ها، زمان پاسخ API، ظرفیت سرور و مصرف منابع بررسی شود. Rate limiting باید بر اساس ظرفیت سیستم تنظیم شود، نه صرفاً بر اساس یک عدد از پیش تعیین‌شده.

جمع‌بندی

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

یه الگوی خیلی رایج توی پروژه‌های Next.js اینه که backend رو هم همون‌جا، توی پوشه‌ی app/api یا pages/api، پیاده می‌کنن. برای یه پروژه‌ی کوچیک یا یه MVP این کار کاملاً منطقیه — چرا یه سرور جدا راه بندازی وقتی همون فریم‌ورک فرانت‌اند می‌تونه چند تا endpoint هم سرو کنه؟ ولی وقتی پروژه بزرگ‌تر میشه، وقتی تعداد endpoint ها از چند تا به چند ده تا میرسه، وقتی نیاز به background job و queue و اتصال به چند تا سرویس خارجی پیدا می‌کنی، همون سادگی اولیه تبدیل به یه مشکل میشه. اینجاست که NestJS وارد بازی میشه.

NestJS دقیقاً چیه؟

NestJS یه فریم‌ورک backend برای Node.js هست که روی TypeScript ساخته شده (هرچند جاوااسکریپت خالص هم پشتیبانی میشه) و زیرش از Express یا Fastify به‌عنوان HTTP server استفاده می‌کنه — خودت انتخاب می‌کنی کدومو بخوای. تفاوت اصلیش با یه فریم‌ورک minimal مثل Express اینه که NestJS یه معماری کامل و opinionated روی سرت میذاره: ماژول‌ها، کنترلرها، provider ها (سرویس‌ها)، و یه سیستم dependency injection که کل این‌ها رو به هم وصل می‌کنه.

یه مثال ساده از یه ماژول در NestJS این شکلیه:

// users.controller.ts
import { Controller, Get, Post, Body, Param } from '@nestjs/common';
import { UsersService } from './users.service';

@Controller('users')
export class UsersController {
  constructor(private readonly usersService: UsersService) {}

  @Get(':id')
  findOne(@Param('id') id: string) {
    return this.usersService.findOne(id);
  }

  @Post()
  create(@Body() createUserDto: CreateUserDto) {
    return this.usersService.create(createUserDto);
  }
}

// users.service.ts
import { Injectable } from '@nestjs/common';

@Injectable()
export class UsersService {
  private users = [];

  findOne(id: string) {
    return this.users.find((u) => u.id === id);
  }

  create(data: CreateUserDto) {
    const user = { id: Date.now().toString(), ...data };
    this.users.push(user);
    return user;
  }
}

اینجا UsersController مسئول گرفتن request هست، و منطق واقعی رفته توی UsersService. نکته‌ی مهم اینه که کنترلر اصلاً نمی‌دونه UsersService چطور ساخته میشه — فقط توی constructor خواستتش، و خود NestJS با سیستم DI اون رو براش می‌سازه و تزریق می‌کنه. این جدایی وقتی پروژه بزرگ میشه، فرق بین یه کدبیس قابل نگهداری و یه فایل ۲۰۰۰ خطی که همه ازش می‌ترسن رو می‌سازه.

چرا به‌جای API route های Next.js؟

API route های Next.js برای یه سری کار خیلی خوب هستن: یه webhook ساده، یه پراکسی کوچیک به یه سرویس دیگه، یا چند تا endpoint که مستقیم به دیتای همون صفحه مربوط میشن. مشکل از جایی شروع میشه که بخوای این API route ها رو به یه backend واقعی تبدیل کنی.

اول از همه، API route ها ساختار معماری ندارن. هیچ الگوی رسمی‌ای برای جدا کردن business logic از لایه‌ی HTTP وجود نداره؛ هر تیمی به روش خودش فایل‌ها رو می‌چینه، و این یعنی هر پروژه‌ی Next.js با بک‌اند بزرگ، یه معماری دست‌ساز و غیر استاندارد داره که فقط خود همون تیم باهاش راحته.

دوم، هیچ dependency injection ای وجود نداره. اگه بخوای یه سرویس دیتابیس رو mock کنی برای تست، یا بخوای پیکربندی مختلف برای محیط‌های مختلف (dev/staging/production) داشته باشی، باید خودت از صفر این infrastructure رو بسازی — چیزی که توی NestJS از روز اول رایگان همراهته.

سوم، قابلیت‌های آماده‌ای مثل guard (برای authorization)، pipe (برای validation و transform کردن ورودی)، interceptor (برای لاگ‌گیری یا caching)، و پشتیبانی built-in از microservices، WebSocket، GraphQL و message queue هایی مثل RabbitMQ و Kafka، همه بخشی از خود فریم‌ورک هستن. توی Next.js API route ها، همه‌ی این‌ها رو باید دستی یا با کتابخونه‌های جداگانه پیاده کنی و خودت به هم وصلشون کنی.

و در آخر، مسئله‌ی جدایی نگرانی‌هاست (separation of concerns). وقتی frontend و backend توی یه codebase و یه پروسه‌ی deploy قاطی میشن، اسکیل کردنشون هم مستقل از هم غیرممکن میشه. اگه backendت نیاز به منابع محاسباتی بیشتری داره ولی frontendت نه، توی Next.js نمی‌تونی این دو تا رو جدا اسکیل کنی؛ ولی وقتی backend یه سرویس مجزای NestJS باشه، این کار پیش‌فرضه.

این به این معنی نیست که Next.js API route ها همیشه اشتباهن. برای پروژه‌های کوچیک، یا وقتی backend واقعاً فقط چند تا وظیفه‌ی ساده داره، اضافه کردن یه فریم‌ورک جدا مثل NestJS ممکنه بیش از حد باشه. سؤال واقعی اینه: آیا backendت قراره رشد کنه و پیچیده بشه، یا همیشه همین‌قدر کوچیک می‌مونه؟

مقایسه با بقیه‌ی فریم‌ورک‌ها

Express پایه و اساس خیلی از فریم‌ورک‌های Node.js از جمله خود NestJS هست. مزیتش انعطاف‌پذیری مطلقشه — هیچ ساختاری بهت تحمیل نمی‌کنه. اما همین انعطاف، مشکل هم هست: توی یه تیم بزرگ، هر توسعه‌دهنده ممکنه یه روش متفاوت برای سازمان‌دهی کد انتخاب کنه، و بعد از یه مدت کدبیس به یه مجموعه‌ی ناهماهنگ از الگوهای مختلف تبدیل میشه. NestJS اساساً یه لایه‌ی معماری روی همین Express (یا Fastify) میذاره تا این مشکل حل بشه.

Fastify به تنهایی روی سرعت و performance تمرکز داره و از Express سریع‌تره، ولی از نظر فلسفه شبیه Expressه: یه فریم‌ورک minimal، نه یه معماری کامل. جالبه که NestJS می‌تونه از Fastify هم به‌عنوان HTTP adapter استفاده کنه، یعنی می‌تونی هم ساختار NestJS رو داشته باشی هم سرعت Fastify رو.

Next.js API routes، همون‌طور که گفتیم، برای کارهای سبک عالیه ولی برای یه backend کامل و مستقل طراحی نشده؛ اساساً بخشی از یه فریم‌ورک فرانت‌اند هست، نه یه فریم‌ورک backend.

اگه بخوای NestJS رو با دنیای بیرون از Node.js مقایسه کنی، شباهت مفهومیش به Spring Boot توی جاوا یا Laravel توی PHP بیشتره تا به Express — همه‌ی این‌ها فریم‌ورک‌های opinionated و کامل هستن که یه معماری استاندارد و ابزارهای آماده برای dependency injection، validation، و routing ارائه میدن. اگه از پیشینه‌ی جاوا یا PHP وارد دنیای Node شده باشی، NestJS احتمالاً برات خیلی آشنا به نظر میاد.

چه زمانی سراغ NestJS نریم؟

اگه پروژه‌ت واقعاً کوچیکه، یا داری یه prototype سریع می‌سازی، یا تیمت با معماری‌های سنگین راحت نیست، NestJS ممکنه سربار غیرضروری اضافه کنه. یادگیریش هم نسبت به یه Express ساده زمان بیشتری می‌بره، چون باید با مفاهیمی مثل ماژول، decorator، و DI آشنا بشی. برای یه API با پنج تا endpoint که قرار نیست رشد کنه، یه Express ساده یا همون API route های Next.js احتمالاً کافیه.

جمع‌بندی

انتخاب بین NestJS و API route های Next.js در نهایت به اندازه و آینده‌ی پروژه‌ت برمی‌گرده. اگه داری یه backend می‌سازی که قراره چند تا سرویس، چند تا تیم، و منطق پیچیده‌ی business رو در خودش جا بده، NestJS یه پایه‌ی معماری محکم بهت میده که از اول جلوی خیلی از مشکلات ساختاری رو می‌گیره. اگه فقط چند تا endpoint کنار یه اپلیکیشن فرانت‌اند نیاز داری، همون API route های Next.js بدون هیچ overhead ای کارتو راه می‌ندازه. مشکل از جایی شروع میشه که یه پروژه‌ی «فقط چند تا endpoint» رو با فرض «همیشه همین‌قدر کوچیک می‌مونه» شروع کنی و بعد از یه سال متوجه بشی داری یه backend کامل رو توی یه پوشه‌ی api مدیریت می‌کنی.

اگه هر بار که یه پروژه‌ی full-stack جدید شروع می‌کنی، خودت رو تو یه چرخه‌ی تکراری می‌بینی (نصب و تنظیم auth، وصل کردن Prisma، نوشتن API routes برای هر عملیات ساده‌ی CRUD، تنظیم ارسال ایمیل، پیکربندی deploy)، Wasp دقیقاً برای حذف همین تکرار طراحی شده. این فریمورک، به‌جای این‌که یه کتابخونه‌ی دیگه به استکت اضافه کنه، یه لایه‌ی تنظیمات سطح‌بالا رو می‌ذاره که کل اپلیکیشن (فرانت‌اند، بک‌اند، دیتابیس، حتی deploy) رو از یه نقطه توصیف می‌کنه.

ایده‌ی اصلی: Web Application Specification

اسم کامل Wasp مخفف Web Application Specification است، و همین اسم فلسفه‌ی طراحیش رو نشون می‌ده. به‌جای این‌که مستقیم کد بک‌اند بنویسی، یه فایل تنظیمات (main.wasp) داری که با یه زبون اختصاصی (DSL) توصیف می‌کنه اپت چه چیزهایی داره: چه route هایی، چه صفحاتی، چه نوع auth ای، چه entity هایی تو دیتابیس. کامپایلر خود Wasp این توصیف رو می‌گیره و کد واقعی React، Node.js، و Prisma رو ازش تولید می‌کنه.

app MyApp {
  wasp: { version: "^0.16.0" },
  title: "My App",
  auth: {
    userEntity: User,
    methods: { email: {} },
    onAuthFailedRedirectTo: "/login"
  }
}

route DashboardRoute { path: "/dashboard", to: DashboardPage }
page DashboardPage {
  authRequired: true,
  component: import { DashboardPage } from "@src/DashboardPage"
}

query getTasks {
  fn: import { getTasks } from "@src/queries.js",
  entities: [Task]
}

entity Task {=psl
  id          Int     @id @default(autoincrement())
  description String
  isDone      Boolean @default(false)
  user        User    @relation(fields: [userId], references: [id])
  userId      Int
psl=}

با همین چند خط، Wasp خودش auth کامل (با redirect خودکار برای صفحات محافظت‌شده)، مدل دیتابیس، و زیرساخت لازم برای query رو می‌سازه؛ چیزی که دستی نوشتنش معمولاً چند صد خط کد می‌طلبه.

RPC به‌جای REST API دستی

یکی از جذاب‌ترین بخش‌های Wasp، مدل ارتباطی client-server شه. به‌جای این‌که خودت endpoint بسازی و بعد جدا یه fetch call بنویسی، فقط یه تابع سرور رو تعریف می‌کنی و Wasp خودش یه hook تایپ‌شده تو کلاینت تولید می‌کنه:

// سمت سرور: src/queries.js
export const getTasks = async (args, context) => {
  return context.entities.Task.findMany({
    where: { userId: context.user.id }
  });
};

// سمت کلاینت: استفاده مستقیم، بدون نوشتن fetch یا API route
import { useQuery, getTasks } from 'wasp/client/operations';

function TaskList() {
  const { data: tasks, isLoading } = useQuery(getTasks);
  if (isLoading) return <div>در حال بارگذاری...</div>;
  return <ul>{tasks.map(t => <li key={t.id}>{t.description}</li>)}</ul>;
}

نکته‌ی مهم اینجاست که تایپ‌های TypeScript بین سرور و کلاینت به‌صورت خودکار sync می‌شن؛ اگه ساختار داده‌ای که از سرور برمی‌گرده عوض بشه، همون لحظه تو کلاینت هم خطای type-check می‌گیری، بدون این‌که خودت مجبور باشی این هماهنگی رو دستی نگه داری.

قابلیت‌های آماده که معمولاً باید خودت بسازی

Wasp خودش رو «batteries-included» معرفی می‌کنه، و این ادعا با فهرست قابلیت‌هاش پشتیبانی می‌شه:

• Auth کامل: ایمیل/پسورد، گوگل، گیت‌هاب، اسلک، مایکروسافت، همه با پیکربندی چند خطی.
• Background jobs: برای کارهایی که نباید request رو بلاک کنن.
• ارسال ایمیل: بدون نیاز به تنظیم دستی SMTP یا SDK جدا.
• Type-safety کامل full-stack: از دیتابیس تا کامپوننت React.
• Deploy با یه دستور: wasp deploy می‌تونه اپ رو مستقیم رو زیرساخت‌های پشتیبانی‌شده بالا بیاره.

نکته‌ی مهم: بدون lock-in

برخلاف پلتفرم‌هایی مثل Firebase یا Supabase که کدت به سرویس اونا وابسته می‌شه، Wasp ادعا می‌کنه هیچ lock-in ای نداره. خروجی کامپایل، کد خام React و Node.js و Prisma است که می‌تونی مستقیم تو پوشه‌ی .wasp/ ببینیش. یعنی اگه یه روز تصمیم گرفتی از Wasp CLI فاصله بگیری، کد تولیدشده رو برمی‌داری و مستقل ازش ادامه می‌دی؛ بدون runtime اختصاصی یا لایه‌ی مخفی سمت سرور.

چرا این روزها خودش رو «فریمورک عصر AI» معرفی می‌کنه

نکته‌ی جالب اینه که Wasp این روزها تمرکز بازاریابیش رو گذاشته رو این‌که برای کدنویسی با agent های هوش مصنوعی بهینه‌ست. استدلالشون اینه: چون Wasp یه توصیف سطح‌بالا و declarative از کل اپلیکیشن داره (نه هزاران فایل پراکنده‌ی boilerplate)، یه agent کدنویس می‌تونه ساختار کامل اپ رو خیلی سریع‌تر «بفهمه» و تغییرات درستی اعمال کنه. خود پروژه یه سری plugin و skill هم برای ابزارهایی مثل Claude Code منتشر کرده که مستقیم دانش Wasp رو به agent اضافه می‌کنه.

جالبه که این رویکرد هیچ ارتباطی به یه provider خاص هوش مصنوعی نداره؛ Wasp خودش هیچ AI داخلی نداره و اگه بخوای یه ویژگی AI به اپت اضافه کنی (مثلاً چت‌بات)، باید مدل دلخواهت (OpenAI، آنتروپیک، یا یه مدل local) رو مثل یه dependency معمولی Node.js وصل کنی؛ چیزی که خودشون توش دخالتی ندارن.

کجا این فریمورک جای خودش رو پیدا می‌کنه

Wasp دقیقاً یه خلأ خاص رو پر می‌کنه: جایی بین انعطاف کامل ولی کاردستی Next.js یا Remix (که همه‌چیز رو خودت وایر می‌کنی)، و انتزاع بالا ولی وابسته‌به-سرویس Firebase یا Supabase (که برای هر چیزی به یه پلتفرم شخص ثالث وابسته‌ای). اگه دنبال یه تجربه‌ی شبیه Rails یا Laravel هستی، ولی می‌خوای تو دنیای TypeScript و React بمونی، Wasp دقیقاً همین رو ارائه می‌ده.

معایب و محدودیت‌ها

طبیعتاً این سطح از انتزاع هزینه هم داره. اکوسیستم Wasp نسبت به Next.js یا حتی Nuxt خیلی کوچیک‌تره؛ تعداد پروژه‌های واقعی، منابع آموزشی، و توسعه‌دهنده‌های آشنا محدودتره. یادگیری DSL اختصاصیش هم یه گام اضافه‌ست، هرچند سینتکسش نسبتاً ساده‌ست. و چون فریمورک هنوز رسماً تو مرحله‌ی beta است (با این‌که برای ساخت بیش از ۵۰ هزار پروژه استفاده شده)، برای پروژه‌های خیلی بزرگ‌مقیاس یا سازمانی، ممکنه بلوغ لازم رو نداشته باشه. علاوه بر این، طبیعت «opinionated» فریمورک یعنی برای اپلیکیشن‌هایی که ساختارشون خیلی از الگوی معمول CRUD/auth/jobs فاصله داره، ممکنه بیشتر از این‌که کمک کنه، محدودت کنه.

جمع‌بندی

اگه داری یه SaaS یا اپلیکیشن full-stack نسبتاً استاندارد می‌سازی (auth، دیتابیس، چند تا صفحه، شاید یه سری background job) و می‌خوای سریع‌تر از صفر شروع کنی، بدون این‌که هفته‌ها وقت صرف wiring کردن قطعات مختلف کنی، Wasp ارزش امتحان کردن داره؛ مخصوصاً که رایگان، متن‌باز، و بدون lock-in است. اگه پروژه‌ت نیاز به کنترل خیلی دقیق روی هر جزئیات معماری داره، یا از قبل تیمی داری که با Next.js یا Nuxt راحته، احتمالاً همون مسیر آشناتر منطقی‌تره.

قبل از این‌که Next.js و Nuxt و بقیه‌ی meta-framework های امروزی به‌وجود بیان، یه پروژه به اسم Meteor (سال ۲۰۱۲) یه ایده‌ی جسورانه رو دنبال می‌کرد: چرا باید فرانت‌اند و بک‌اند رو با دو تا زبون و دو تا مدل ذهنی جدا بنویسیم، وقتی جاوااسکریپت می‌تونه هر دو طرف رو پوشش بده؟ Meteor یکی از اولین فریمورک‌های full-stack جاوااسکریپتی بود که این ایده رو جدی گرفت و هنوز هم، با این‌که دیگه اسم پرطرفداری نیست، تو بعضی حوزه‌ها (خصوصاً اپلیکیشن‌های real-time) استفاده می‌شه.

ایده‌ی اصلی: یه codebase، دو تا محیط اجرا

تو Meteor، همون فایل جاوااسکریپت می‌تونه هم رو سرور اجرا بشه، هم رو کلاینت؛ فریمورک با یه سیستم build خودش تشخیص می‌ده کدوم بخش کجا باید اجرا بشه. برای این کار از پوشه‌های خاص استفاده می‌کنه:

imports/
  ui/          # کامپوننت‌های React یا Blaze (فقط کلاینت)
  api/         # منطق مشترک و تعریف Collection ها
server/
  main.js      # فقط رو سرور اجرا می‌شه
client/
  main.js      # فقط رو کلاینت اجرا می‌شه

کدی که تو پوشه‌ی server باشه، هیچ‌وقت به مرورگر فرستاده نمی‌شه (نه حتی خودش، نه secret هایی که توش استفاده شده)، و کدی که تو client باشه فقط رو مرورگر اجرا می‌شه. کدی که بیرون از این پوشه‌ها (مثلاً تو imports) باشه، رو هر دو طرف اجرا می‌شه؛ همین قابلیت اشتراک کد بین سرور و کلاینتِ که یکی از اصلی‌ترین وعده‌های Meteor بود.

DDP و reactivity در سطح شبکه

نکته‌ای که Meteor رو واقعاً متفاوت می‌کنه، پروتکل اختصاصیش به اسم DDP (Distributed Data Protocol) است. به‌جای مدل معمول request-response که تو اکثر اپ‌های وب می‌بینی، Meteor یه اتصال WebSocket دائمی بین کلاینت و سرور برقرار می‌کنه و داده رو به‌صورت reactive سینک می‌کنه:

// تعریف یه Collection (شبیه یه جدول/کالکشن دیتابیس)
import { Mongo } from 'meteor/mongo';
export const Tasks = new Mongo.Collection('tasks');

// سمت کلاینت: subscribe به یه دسته از داده
Meteor.subscribe('tasks.all');

// تو یه کامپوننت React، این query خودش reactive است
const tasks = useTracker(() => Tasks.find({}).fetch());

وقتی یه کاربر دیگه یه task جدید اضافه کنه، Collection سمت کلاینت به‌صورت خودکار آپدیت می‌شه و کامپوننت React (به لطف useTracker) دوباره رندر می‌شه؛ همه‌ی این‌ها بدون این‌که خودت مستقیم WebSocket handler بنویسی یا polling بزنی. این دقیقاً چیزیه که Meteor رو برای اپلیکیشن‌های real-time (چت، داشبورد زنده، ابزارهای همکاری تیمی) جذاب می‌کنه.

MongoDB به‌عنوان دیتابیس پیش‌فرض

Meteor از اول با MongoDB طراحی شده و این وابستگی عمیقه؛ نه یه انتخاب سطحی. سیستم reactivity، سینک شدن Collection ها بین سرور و کلاینت، و حتی امکان اجرای query های MongoDB مستقیم تو کلاینت (با یه minimongo که تو حافظه‌ی مرورگر اجرا می‌شه)، همه بر پایه‌ی مدل داده‌ی MongoDB ساخته شدن. اگه پروژه‌ت نیاز به یه دیتابیس رابطه‌ای مثل PostgreSQL داره، می‌شه با یه‌کم کار اضافه بهش وصلش کرد، ولی دیگه از خیلی از مزیت‌های خودکار Meteor بی‌بهره می‌مونی.

مزیت‌ها

سرعت توسعه‌ی اولیه: برای پروتوتایپ کردن سریع یه اپ real-time، کمتر فریمورکی می‌تونه به سرعت Meteor برسه؛ چون خیلی از کارهایی که معمولاً باید دستی پیاده‌سازی کنی (WebSocket، sync داده، hot code push) از قبل آماده‌ست.

Hot code push: Meteor می‌تونه آپدیت‌های جدید رو به کلاینت‌های متصل، بدون نیاز به رفرش کامل صفحه، پوش کنه.

بسته‌بندی کامل: بیلد، bundling، و حتی deploy (با Galaxy، سرویس هاستینگ خود Meteor، یا Docker) همه از قبل تو اکوسیستم فریمورک هماهنگ شدن.

معایب و محدودیت‌ها

وابستگی سنگین به MongoDB: اگه تیمت یا پروژه‌ت به یه دیتابیس رابطه‌ای نیاز داره، Meteor دیگه اون تجربه‌ی یکپارچه رو نمی‌ده.

اکوسیستم کوچیک‌تر و کم‌رونق‌تر: Meteor دیگه اون momentum اوایل دهه‌ی ۲۰۱۰ رو نداره. تعداد کتابخونه‌ها، تعداد سؤال‌های Stack Overflow، و تعداد پروژه‌های جدیدی که باهاش شروع می‌شن به‌طور محسوسی از React یا Vue خام (چه برسه به Next.js یا Nuxt) کمتره.

سایز باندل کلاینت: به‌خاطر minimongo و DDP client که باید رو مرورگر لود بشن، سایز باندل اولیه‌ی Meteor معمولاً بزرگ‌تر از یه اپ ساده‌ی React یا Vue است.

منحنی یادگیری غیرمستقیم: مفاهیمی مثل Collection، publication/subscription، و method call (روش استاندارد Meteor برای mutation) یه مدل ذهنی جدا از چیزیه که تو REST یا GraphQL معمول یاد می‌گیری؛ یعنی دانشش کمتر قابل‌انتقاله به پروژه‌های دیگه.

کجا هنوز منطقیه

اگه داری یه اپ کاملاً real-time می‌سازی (مثل یه ابزار همکاری زنده، یه چت، یا یه داشبورد که باید فوری آپدیت بشه)، و مشکلی با MongoDB به‌عنوان دیتابیس اصلی نداری، Meteor هنوز می‌تونه سرعت توسعه‌ی بالایی بهت بده؛ خصوصاً برای تیم‌های کوچیک یا MVP هایی که سرعت رسیدن به بازار مهم‌تر از انعطاف بلندمدت معماریه.

برای پروژه‌های عمومی‌تر که نیاز به real-time فوری ندارن، یا تیمت ترجیح می‌ده از یه استک رابطه‌ای و ابزارهای مدرن‌تر مثل Next.js یا Nuxt استفاده کنه، احتمالاً امروز گزینه‌های بهتری نسبت به Meteor پیدا می‌کنی؛ نه به این خاطر که Meteor بد شده، بلکه چون بقیه‌ی اکوسیستم جاوااسکریپت از اون موقع به‌طور قابل‌توجهی رشد کرده و خیلی از ایده‌های خوب Meteor (مثل full-stack بودن) رو به روش‌های مدرن‌تری پیاده کردن.

سه روز بعد از اینکه TypeSafe AI مدل Jev رو منتشر کرد، یه مدل متن‌باز به اسم Laya ظاهر شد که خودش رو «جایگزین رایگان و لوکال Jev» معرفی می‌کرد. مخزن گیت‌هابش توی هشت روز بیش از ۲۴ هزار ستاره گرفت و همین باعث شد سؤال طبیعی پیش بیاد: اگه یه مدل تصمیم‌گیر رایگان هست که روی لپ‌تاپ خودت اجرا میشه، چرا باید برای Jev پول بدی؟ جواب کوتاه اینه که بستگی داره — و جواب بلند چیزیه که این مقاله سعی می‌کنه بده.

Laya دقیقاً چیه؟

Laya یه خانواده‌ی مدل تصمیم‌گیر non-autoregressive از شرکت Convai Innovations (به سرپرستی ناندا‌کیشور مکونوت) هست که تحت لایسنس Apache-2.0 و در ۱۸ سپتامبر ۲۰۲۶ منتشر شد. ایده‌ش دقیقاً همون ایده‌ی Jevه: یه state و چند سؤال typed بهش میدی، و به‌جای متن، در یه forward pass جواب ساختاریافته با احتمال واقعی برمی‌گردونه. همون سه primitive آشنا رو هم داره: choice، score و noul (بله/خیر با احتمال). سه تا checkpoint داره: یه مدل ۴۲۱ میلیون پارامتری انگلیسی، یه مدل ۳۲۲ میلیون پارامتری چندزبانه که بیش از ۱۰۰ زبان رو پوشش میده، و یه checkpoint مخصوص typed decisions. نصبش هم یه pip install laya ساده‌ست و روی یه GPU رایگان T4 یا حتی یه مک ۱۶ گیگی اجرا میشه.

یه نکته‌ی جالب درباره‌ی پیشینه‌ش: نویسنده‌ی Laya میگه کار پایه‌ای این ایده رو مارس ۲۰۲۵ به‌صورت preprint منتشر کرده بود، یعنی حدود ۱۸ ماه قبل از Jev، و Laya رو نسخه‌ی «کاملاً باز و بدون محدودیت‌های معماری قبلی» اون کار می‌دونه. با این حال، هیچ مدرکی نشون داده نشده که Jev از پیاده‌سازی اون استفاده کرده باشه و TypeSafe هم تا الان علناً واکنشی نشون نداده؛ پس این بخش رو باید به‌عنوان ادعای نویسنده دید، نه یه واقعیت اثبات‌شده. یه نکته‌ی روشن‌کننده دیگه هم اینه که رابط Laya عمداً شبیه Jev طراحی شده، ولی Laya محصول TypeSafe نیست و هیچ ارتباط رسمی‌ای بینشون وجود نداره.

عددها چی میگن؟ (و چرا باید بهشون شک کرد)

اینجا جاییه که باید خیلی با احتیاط جلو رفت. مدل‌کارت Laya ادعا می‌کنه که روی یه بنچمارک، دقتش ۷۶.۶٪ در برابر ۷۲.۷٪ Jev هست، و تأخیرش حدود ۳۳ میلی‌ثانیه روی T4 در برابر ۲۳۶ تا ۲۷۶ میلی‌ثانیه Jev، یعنی حدود ۷.۸ برابر سریع‌تر. ولی خود نویسنده‌های Laya هم اعتراف می‌کنن که اعداد Jev رو خودشون اندازه نگرفتن و از اندازه‌گیری‌های شخص ثالث برداشتن. چند تا مشکل جدی توی این مقایسه هست:

• عدد ۷۶.۶٪ مال checkpoint ای هست که روی خود split آموزشی همون بنچمارک fine-tune شده؛ مدل پایه‌ی zero-shot فقط ۳۶.۲٪ گرفته، که حتی از baseline اکثریت (۴۶.۱٪) هم پایین‌تره.
• مقایسه‌ی سرعت، یه inference لوکال روی GPU گرم‌شده رو با یه فراخوانی API میزبانی‌شده (که زمان شبکه رو هم شامل میشه) مقایسه می‌کنه — یعنی سیب و پرتقال.
• روی Banking77 که باید بین ۷۷ برچسب intent انتخاب کنی، Jev عدد ۰.۸۷۰ گرفته و Laya فقط ۰.۴۲۵؛ یعنی روی دسته‌بندی‌های با تعداد برچسب بالا، Jev فاصله‌ی زیادی داره و برای Laya باید سلسله‌مراتب coarse-to-fine بسازی.
• خود مدل‌کارت Laya هشدار میده که مدل تا وقتی temperature ش دوباره calibrate نشه، بیش‌ازحد مطمئن (overconfident) خروجی میده — که برای مدلی که ارزشش توی احتمال‌های واقعیه، یه نکته‌ی کوچیک نیست.

یه تست مستقل که هر دو مدل رو روی یه مجموعه‌ی ۴۰۰ تصمیمی و توی یه harness یکسان اجرا کرده، نتیجه‌ی متعادل‌تری داده: Laya روی دو تا از شش سؤال جلو بوده و توی بقیه Jev برتری داشته. سرعت Laya روی مک بین ۲۰ تا ۵۰ میلی‌ثانیه بوده که واقعاً چشمگیره، ولی دقتش به‌طور کلی پایین‌تر از Jev بوده.

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

پس کدوم رو استفاده کنیم؟

جواب صادقانه اینه که این‌ها جایگزین هم نیستن، دو تا ابزار برای دو تا موقعیت متفاوتن. اگه دقت روی برچسب‌های زیاد یا سؤال‌های پیچیده‌تر براش مهمه، نمی‌خوای زیرساخت اجرای مدل رو خودت نگه داری، و ارسال داده به یه API خارجی مشکلی نداره، Jev هنوز انتخاب امن‌تریه. ولی اگه داده‌هات حساسن و نباید از سرورت خارج بشن، حجم فراخوانی اونقدر بالاست که حتی هزینه‌ی ناچیز به ازای هر توکن هم جمع میشه، تأخیر چندده‌میلی‌ثانیه‌ای برات حیاتیه (مثلاً یه حلقه‌ی کنترل real-time)، یا با متن چندزبانه کار می‌کنی، Laya قابل‌توجه‌تره — به شرط اینکه حاضر باشی یه مقدار وقت برای fine-tune و calibrate کردنش بذاری.

پیشنهاد عملی من اینه که به هیچ‌کدوم از اعداد منتشرشده‌ی هیچ‌طرفی تکیه نکنی: ۲۰۰ تا ۵۰۰ نمونه‌ی واقعی از داده‌ی خودت جمع کن، برچسب‌گذاریشون کن، و هر دو مدل رو روی همون‌ها امتحان کن. چون Laya رایگانه و توی چند دقیقه نصب میشه، این تست تقریباً بی‌هزینه‌ست، و نتیجه‌ش خیلی بیشتر از هر بنچمارک عمومی به کارت میاد. اگه Laya روی داده‌ی تو به دقت قابل‌قبولی رسید، یه مدل لوکال رایگان با تأخیر چندده‌میلی‌ثانیه‌ای ارزش جدی داره؛ اگه نرسید، هزینه‌ی Jev احتمالاً همچنان از خطاهای اضافی ارزون‌تره.

سه روز بعد از اینکه TypeSafe AI مدل Jev رو منتشر کرد، یه مدل متن‌باز به اسم Laya ظاهر شد که خودش رو «جایگزین رایگان و لوکال Jev» معرفی می‌کرد. مخزن گیت‌هابش توی هشت روز بیش از ۲۴ هزار ستاره گرفت و همین باعث شد سؤال طبیعی پیش بیاد: اگه یه مدل تصمیم‌گیر رایگان هست که روی لپ‌تاپ خودت اجرا میشه، چرا باید برای Jev پول بدی؟ جواب کوتاه اینه که بستگی داره — و جواب بلند چیزیه که این مقاله سعی می‌کنه بده.

Laya دقیقاً چیه؟

Laya یه خانواده‌ی مدل تصمیم‌گیر non-autoregressive از شرکت Convai Innovations (به سرپرستی ناندا‌کیشور مکونوت) هست که تحت لایسنس Apache-2.0 و در ۱۸ سپتامبر ۲۰۲۶ منتشر شد. ایده‌ش دقیقاً همون ایده‌ی Jevه: یه state و چند سؤال typed بهش میدی، و به‌جای متن، در یه forward pass جواب ساختاریافته با احتمال واقعی برمی‌گردونه. همون سه primitive آشنا رو هم داره: choice، score و noul (بله/خیر با احتمال). سه تا checkpoint داره: یه مدل ۴۲۱ میلیون پارامتری انگلیسی، یه مدل ۳۲۲ میلیون پارامتری چندزبانه که بیش از ۱۰۰ زبان رو پوشش میده، و یه checkpoint مخصوص typed decisions. نصبش هم یه pip install laya ساده‌ست و روی یه GPU رایگان T4 یا حتی یه مک ۱۶ گیگی اجرا میشه.

یه نکته‌ی جالب درباره‌ی پیشینه‌ش: نویسنده‌ی Laya میگه کار پایه‌ای این ایده رو مارس ۲۰۲۵ به‌صورت preprint منتشر کرده بود، یعنی حدود ۱۸ ماه قبل از Jev، و Laya رو نسخه‌ی «کاملاً باز و بدون محدودیت‌های معماری قبلی» اون کار می‌دونه. با این حال، هیچ مدرکی نشون داده نشده که Jev از پیاده‌سازی اون استفاده کرده باشه و TypeSafe هم تا الان علناً واکنشی نشون نداده؛ پس این بخش رو باید به‌عنوان ادعای نویسنده دید، نه یه واقعیت اثبات‌شده. یه نکته‌ی روشن‌کننده دیگه هم اینه که رابط Laya عمداً شبیه Jev طراحی شده، ولی Laya محصول TypeSafe نیست و هیچ ارتباط رسمی‌ای بینشون وجود نداره.

عددها چی میگن؟ (و چرا باید بهشون شک کرد)

اینجا جاییه که باید خیلی با احتیاط جلو رفت. مدل‌کارت Laya ادعا می‌کنه که روی یه بنچمارک، دقتش ۷۶.۶٪ در برابر ۷۲.۷٪ Jev هست، و تأخیرش حدود ۳۳ میلی‌ثانیه روی T4 در برابر ۲۳۶ تا ۲۷۶ میلی‌ثانیه Jev، یعنی حدود ۷.۸ برابر سریع‌تر. ولی خود نویسنده‌های Laya هم اعتراف می‌کنن که اعداد Jev رو خودشون اندازه نگرفتن و از اندازه‌گیری‌های شخص ثالث برداشتن. چند تا مشکل جدی توی این مقایسه هست:

• عدد ۷۶.۶٪ مال checkpoint ای هست که روی خود split آموزشی همون بنچمارک fine-tune شده؛ مدل پایه‌ی zero-shot فقط ۳۶.۲٪ گرفته، که حتی از baseline اکثریت (۴۶.۱٪) هم پایین‌تره.
• مقایسه‌ی سرعت، یه inference لوکال روی GPU گرم‌شده رو با یه فراخوانی API میزبانی‌شده (که زمان شبکه رو هم شامل میشه) مقایسه می‌کنه — یعنی سیب و پرتقال.
• روی Banking77 که باید بین ۷۷ برچسب intent انتخاب کنی، Jev عدد ۰.۸۷۰ گرفته و Laya فقط ۰.۴۲۵؛ یعنی روی دسته‌بندی‌های با تعداد برچسب بالا، Jev فاصله‌ی زیادی داره و برای Laya باید سلسله‌مراتب coarse-to-fine بسازی.
• خود مدل‌کارت Laya هشدار میده که مدل تا وقتی temperature ش دوباره calibrate نشه، بیش‌ازحد مطمئن (overconfident) خروجی میده — که برای مدلی که ارزشش توی احتمال‌های واقعیه، یه نکته‌ی کوچیک نیست.

یه تست مستقل که هر دو مدل رو روی یه مجموعه‌ی ۴۰۰ تصمیمی و توی یه harness یکسان اجرا کرده، نتیجه‌ی متعادل‌تری داده: Laya روی دو تا از شش سؤال جلو بوده و توی بقیه Jev برتری داشته. سرعت Laya روی مک بین ۲۰ تا ۵۰ میلی‌ثانیه بوده که واقعاً چشمگیره، ولی دقتش به‌طور کلی پایین‌تر از Jev بوده.

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

پس کدوم رو استفاده کنیم؟

جواب صادقانه اینه که این‌ها جایگزین هم نیستن، دو تا ابزار برای دو تا موقعیت متفاوتن. اگه دقت روی برچسب‌های زیاد یا سؤال‌های پیچیده‌تر براش مهمه، نمی‌خوای زیرساخت اجرای مدل رو خودت نگه داری، و ارسال داده به یه API خارجی مشکلی نداره، Jev هنوز انتخاب امن‌تریه. ولی اگه داده‌هات حساسن و نباید از سرورت خارج بشن، حجم فراخوانی اونقدر بالاست که حتی هزینه‌ی ناچیز به ازای هر توکن هم جمع میشه، تأخیر چندده‌میلی‌ثانیه‌ای برات حیاتیه (مثلاً یه حلقه‌ی کنترل real-time)، یا با متن چندزبانه کار می‌کنی، Laya قابل‌توجه‌تره — به شرط اینکه حاضر باشی یه مقدار وقت برای fine-tune و calibrate کردنش بذاری.

پیشنهاد عملی من اینه که به هیچ‌کدوم از اعداد منتشرشده‌ی هیچ‌طرفی تکیه نکنی: ۲۰۰ تا ۵۰۰ نمونه‌ی واقعی از داده‌ی خودت جمع کن، برچسب‌گذاریشون کن، و هر دو مدل رو روی همون‌ها امتحان کن. چون Laya رایگانه و توی چند دقیقه نصب میشه، این تست تقریباً بی‌هزینه‌ست، و نتیجه‌ش خیلی بیشتر از هر بنچمارک عمومی به کارت میاد. اگه Laya روی داده‌ی تو به دقت قابل‌قبولی رسید، یه مدل لوکال رایگان با تأخیر چندده‌میلی‌ثانیه‌ای ارزش جدی داره؛ اگه نرسید، هزینه‌ی Jev احتمالاً همچنان از خطاهای اضافی ارزون‌تره.

پی اچ پی 8.6 هنوز رسماً منتشر نشده — feature freeze ش ۲۲ سپتامبر بسته شد، اولین release candidate دو روز بعدش اومد، و تاریخ انتشار نهایی ۱۹ نوامبر ۲۰۲۶ برنامه‌ریزی شده. یعنی الان دقیقاً بهترین زمانه که بشینی و ببینی قراره چه چیزهایی توی این نسخه بیاد، قبل از اینکه واقعاً مجبور بشی باهاشون کار کنی. برخلاف PHP 8.5 که بیشتر یه نسخه‌ی incremental بود، این‌بار چند تا تغییر واقعاً روی نحوه‌ی نوشتن روزمره‌ی کد اثر می‌ذارن.

Partial Function Application، ستاره‌ی این نسخه

بدون شک بحث‌برانگیزترین و پرکاربردترین ویژگی این نسخه، Partial Function Application یا PFA هست. ایده‌ش اینه که بتونی بعضی از آرگومان‌های یه تابع رو از قبل پر کنی و یه closure برگردونی که فقط بقیه‌ی آرگومان‌ها رو می‌خواد. قبلاً برای این کار مجبور بودی دستی یه closure بنویسی:

// قبل از PHP 8.6
$smsSender = function (int $uid, string $msg) {
    return sendNotification('SMS', $uid, $msg);
};

حالا با سینتکس جدید و علامت ? به‌عنوان جای‌خالی، همین کار یه‌خطی میشه:

// PHP 8.6
$smsSender = sendNotification('SMS', ?, ?);
$smsSender(1001, 'سفارشت ارسال شد');

یه نکته‌ی فنی مهم اینجاست که هر ? دقیقاً یعنی یه آرگومان که باید بعداً پر بشه، و طبق تصمیم نهایی RFC، حتی اگه پارامتر اصلی optional بوده باشه، توی closure نهایی به یه پارامتر required تبدیل میشه. مقادیری هم که موقع ساختن partial پاس میدی (مثل 'SMS' بالا)، همون لحظه ارزیابی میشن، نه موقع صدا زدن closure نهایی. جالبه که این پیشنهاد یه‌بار توی سال ۲۰۲۱ رد شده بود، و نسخه‌ی دومش این‌بار با رأی ۳۳ به صفر تصویب شده.

مقدار پیش‌فرض برای readonly property

از PHP 8.6 به بعد، می‌تونی به property های readonly مقدار پیش‌فرض بدی — چیزی که تا الان مجبور بودی حتماً توی constructor مقداردهیش کنی:

final class CreateBooksTable
{
    public readonly string $name = '2026-01-01_create_books_table';
}

این تغییر کاملاً additive هست، یعنی هیچ کد قدیمی‌ای که constructor خودش مقداردهی می‌کرد رو نمی‌شکنه.

یه Polling API یکپارچه و native

یکی از فنی‌ترین اضافه‌های این نسخه یه Polling API واحده که هم توی سطح داخلی PHP و هم توی سطح userland قابل استفاده‌ست. این API به‌صورت native از event dispatch سیستم‌عامل استفاده می‌کنه: روی لینوکس از epoll، روی مک و BSD از kqueue، و روی ویندوز از WSAPoll. هدف این قابلیت اینه که پایه‌ای برای معماری‌های async نسل بعدی PHP باشه، به‌جای اینکه هر کتابخونه مجبور باشه خودش یه لایه‌ی polling جدا پیاده کنه.

Duration، یه کلاس رسمی برای زمان

کلاس جدید Time\Duration یه راه رسمی برای نمایش یه بازه‌ی زمانی با دقت نانوثانیه‌ست، شبیه یه stopwatch. متدهای factory برای هر واحد زمانی (ثانیه، میلی‌ثانیه و…)، عملیات ریاضی، و مقایسه رو پشتیبانی می‌کنه، و حتی می‌تونی از یه رشته‌ی ISO 8601 هم بسازیش. ایده اینه که این کلاس به‌جای عدد صحیح یا اعشاری خام، به‌عنوان یه نوع مشترک بین توابع core و همون Polling API جدید استفاده بشه.

چند تا اضافه‌ی کوچیک‌تر ولی مفید

کنار این سه ویژگی اصلی، چند تا اضافه‌ی کوچیک‌تر هم توی PHP 8.6 هست که به‌مرور توی کد روزمره حس میشن:

• یه تابع سراسری جدید به اسم clamp() که یه مقدار رو در صورت خارج بودن از یه بازه، به نزدیک‌ترین کران محدود می‌کنه.
• توابع reflection جدید isReadable و isWriteable برای بررسی دقیق‌تر property ها.
• پشتیبانی از doc comment مستقیم روی پارامترهای تابع.
• یه enum جدید به اسم SortDirection برای اینکه دیگه مجبور نباشی رشته‌های دستی مثل 'asc' و 'desc' پخش کنی.
• بهبود امنیت مقادیر پیش‌فرض session، که برای خیلی از پروژه‌های قدیمی یه نقطه‌ضعف رایج بوده.
• قابلیت debug بهتر برای enum ها، که تا الان توی var_dump یا دیباگ کردن همیشه کمی گنگ بودن.
• پشتیبانی از #[\Override] روی class constant ها، شبیه همون attribute ای که قبلاً فقط روی متدها قابل استفاده بود.

و یه سری deprecation، طبق روال همیشگی

مثل هر نسخه‌ی PHP دیگه‌ای، این نسخه هم یه سری قابلیت قدیمی رو deprecated می‌کنه. لیست کامل این deprecation ها هنوز داره کامل میشه، برای همین اگه پروژه‌ی بزرگی داری، بهتره نزدیک انتشار نهایی یه‌بار changelog رو کامل مرور کنی، نه همین الان.

جمع‌بندی: ارزش صبر کردن رو داره؟

اگه بخوای یه‌خط جمع‌بندی کنی: PFA بزرگ‌ترین تغییر syntax این نسخه‌ست و واقعاً نحوه‌ی نوشتن callback و کد functional رو تمیزتر می‌کنه؛ Duration و Polling API بیشتر زیرساخت آینده‌ی PHP رو می‌سازن تا اینکه همین امروز مستقیم روی کدت اثر بذارن؛ و بقیه‌ی موارد بیشتر quality-of-life هستن. با توجه به اینکه هنوز توی مرحله‌ی RC هستیم، منطقی‌ترین کار اینه که همین حالا نسخه‌ی بتا رو (مثلاً از طریق ایمیج داکر php:8.6-rc-cli یا کامپایل از سورس) روی یه پروژه‌ی تست امتحان کنی، ولی برای production صبر کنی تا نوامبر که نسخه‌ی نهایی و پایدار بیاد.

این هفته یه استارتاپ کمتر شناخته‌شده به اسم TypeSafe AI یه مدل منتشر کرد که به‌جای رقابت توی همون مسیر همیشگی «مدل بزرگ‌تر، reasoning بهتر، context طولانی‌تر»، مسیر کاملاً متفاوتی رو انتخاب کرده. اسم این مدل Jev هست، و برخلاف تقریباً هر مدل دیگه‌ای که این روزها می‌بینیم، اصلاً یه LLM به معنای رایج کلمه نیست.

چی می‌سازتش خاص؟

بنیان‌گذار TypeSafe AI، دیه‌گو آلمیدا، قبلاً توی اوپن‌ای‌آی روی RLHF کار می‌کرده — همون فرآیندی که یه مدل زبانی خام رو به چیزی مثل ChatGPT تبدیل کرد. بعد از دو سال کار مخفیانه و جذب ۴۰ میلیون دلار سرمایه، حالا اولین محصول این شرکت رو معرفی کرده. ایده‌ی اصلی TypeSafe اینه که خیلی از کاربردهای هوش مصنوعی توی نرم‌افزار، اصلاً نیازی به یه پاراگراف متن ندارن؛ فقط یه بله/خیر، یه عدد، یا یه دسته‌بندی می‌خوان. برای همین Jev رو به‌عنوان چیزی که خودشون «System 1 Model» می‌نامنش معرفی کردن — اشاره‌ای به مفهوم تفکر سریع و کند دنیل کانمن.

فرق اصلیش با یه LLM معمولی اینجاست: یه LLM معمولی به‌صورت autoregressive کار می‌کنه، یعنی یه توکن تولید می‌کنه، بعد بر اساس همون توکن، توکن بعدی رو پیش‌بینی می‌کنه، و همین‌طور ادامه میده تا جمله کامل بشه. Jev کاملاً این چرخه رو کنار گذاشته: به‌جای تولید متن توکن‌به‌توکن، در یه پاس واحد یه تصمیم ساختاریافته برمی‌گردونه — یه احتمال، یه امتیاز اطمینان، یا یه مقدار typed.

مثال عملی: state، questions، و جواب typed

برای اینکه این تفاوت رو ملموس‌تر ببینی، بیا یه سناریوی واقعی رو با هم مرور کنیم: یه تیکت پشتیبانی که باید هم‌زمان مشخص بشه فوریه یا نه، شکایته یا نه، و باید به کدوم صف بره. به Jev یه «state» (متن یا دیتای زمینه) و یه مجموعه «questions» با نوع مشخص میدی — سه نوع اصلی که پشتیبانی می‌کنه Noul (بله/خیر با احتمال)، Choice (انتخاب از بین چند گزینه)، و Score (امتیاز روی یه معیار مرتب) هستن:

import { experimental_evaluate as evaluate } from 'ai';

const result = await evaluate({
  model: 'typesafe-ai/jev',
  state: 'دیروز دو بار ازم پول کم شده، همین امروز باید حلش کنین وگرنه اکانتمو می‌بندم.',
  questions: {
    is_urgent: {
      type: 'boolean',
      instructions: 'آیا این پیام فوریه؟',
    },
    queue: {
      type: 'choice',
      options: ['billing', 'technical', 'general'],
      instructions: 'این تیکت باید به کدوم صف بره؟',
    },
    frustration_level: {
      type: 'score',
      scale: [1, 5],
      instructions: 'سطح نارضایتی مشتری رو از ۱ تا ۵ بسنج.',
    },
  },
});

خروجی این فراخوانی، به‌جای یه پاراگراف توضیحی، یه شیء ساختاریافته با احتمال کنار هر جوابه، چیزی شبیه این:

{
  "answers": {
    "is_urgent": { "value": true, "probability": 0.94 },
    "queue": { "value": "billing", "probability": 0.88 },
    "frustration_level": { "value": 4, "probability": 0.81 }
  },
  "usage": { "input_tokens": 42, "output_tokens": 3 }
}

نکته‌ی مهم اینجا اینه که هر سه تا سؤال هم‌زمان و موازی ارزیابی شدن، نه به‌صورت سه فراخوانی جدا، و کد تو مستقیم می‌تونه روی is_urgent.value یا queue.value شرط بذاره — بدون parse کردن یه متن آزاد یا امیدوار بودن به اینکه مدل فرمت JSON رو درست رعایت کرده باشه. همین چیزیه که TypeSafe بهش میگه حذف مرحله‌ی «تولید متن غیرضروری».

چرا این‌قدر سریع و ارزونه؟

TypeSafe میگه معماری Jev، همراه با یه sampler موازی جدید و یه روش آموزشی به اسم Reinforcement Learning for Calibrated Decisions، باعث شده این مدل بتونه چند تا سؤال تعریف‌شده رو هم‌زمان ارزیابی کنه. ادعاهای این شرکت درباره‌ی سرعت و هزینه واقعاً چشمگیرن: طبق گزارش‌های خودشون، Jev تا ۱۹۳.۶ برابر سریع‌تر و تا ۴۴۴.۶ برابر ارزون‌تر از LLM های معمول روی ارزیابی‌های workflow عمل کرده. قیمت‌گذاریش هم غیرمعموله: ورودی به ازای هر میلیارد توکن (نه میلیون) حدود ۴۲ دلاره، در حالی که خروجی عملاً رایگانه — چون متن طولانی‌ای تولید نمیشه که بابتش هزینه بگیرن. یه نکته‌ی مهم دیگه اینه که چون خروجی‌ها از قبل محدود به یه فرمت مشخص هستن، طبق ادعای TypeSafe این مدل عملاً نمی‌تونه دچار hallucination بشه.

کجا استفاده میشه و اکوسیستمش چقدر جدیه؟

Jev قرار نیست جای ChatGPT رو بگیره؛ نمی‌تونه ایمیل بنویسه یا مکالمه کنه. جایی که معنا پیدا می‌کنه، داخل نقاط تصمیم‌گیری یه اپلیکیشنه: انتخاب ابزار یا subagent بعدی توی یه حلقه‌ی agent، تصمیم بین ادامه‌دادن/تلاش دوباره/پرسیدن از کاربر/توقف، امتیازدهی به فوریت یا ریسک قبل از یه اقدام، و راستی‌آزمایی خروجی یه مدل دیگه برای guardrail. طبق مستندات، محدودیتش اینه که فقط ورودی متنی می‌پذیره و سقف context اون ۳۲ هزار توکنه — یعنی برای دیتای خیلی حجیم مناسب نیست.

اکوسیستم دورش هم سریع شکل گرفته: Jev همین الان از طریق AI Gateway ورسل و AI SDK (با متد آزمایشی evaluate)، پلتفرم‌هایی مثل orq.ai و LiteLLM (به‌عنوان proxy)، و ابزار observability مثل Braintrust (برای ردیابی سؤال‌ها، جواب‌ها و توزیع احتمالات) در دسترسه. کتابخونه‌های رسمی پایتون و جاوااسکریپت وجود دارن، و حتی یه SDK غیررسمی راست هم توسط کامیونیتی نوشته شده. یه ریپازیتوری کامیونیتی هم به اسم awesome-jev-by-typesafe الگوها و نمونه‌کدهای مختلف استفاده از این مدل رو جمع کرده — نشونه‌ی اینکه توسعه‌دهنده‌ها خیلی سریع دارن دنبال جای مناسبش توی stack خودشون می‌گردن.

بررسی کامل: نقاط قوت و محدودیت‌ها

نقطه‌قوت اصلی Jev اینه که یه دسته از مسائل رو که همیشه با یه LLM معمولی حل می‌کردیم — دسته‌بندی، routing، امتیازدهی — رو ارزون‌تر، سریع‌تر و قابل‌اعتمادتر (از نظر فرمت خروجی) می‌کنه؛ دیگه لازم نیست نگران parse کردن یه JSON ناقص یا یه توضیح اضافه‌ی غیرمنتظره باشی. برگردوندن احتمال کنار هر جواب هم یه مزیت عملیه: می‌تونی موارد مطمئن رو خودکار پردازش کنی و فقط موارد مبهم رو برای بررسی انسانی نگه داری، الگویی که توی خیلی از نمونه‌کدهای منتشرشده هم دیده میشه.

از طرف دیگه، چند تا محدودیت هم داره که باید در نظرشون بگیری. اول، ورودی فقط متنیه، یعنی برای تصمیم‌گیری بر پایه‌ی تصویر یا صدا اصلاً گزینه نیست. دوم، سقف context ۳۲ هزار توکنی یعنی برای state های خیلی بزرگ (مثلاً یه سند طولانی) باید اول خلاصه‌سازی یا فیلتر انجام بدی. سوم، و شاید مهم‌تر از همه، ارقام چشمگیر سرعت و هزینه‌ای که TypeSafe منتشر کرده، بر پایه‌ی benchmark و روش ارزیابی خودشونه؛ یه مقایسه‌ی مستقل که یکی از کاربرها بین Jev و Gemini برای دسته‌بندی ایمیل انجام داده بود نشون داد Gemini کمی دقیق‌تر عمل کرده، هرچند ده تا بیست برابر گرون‌تر بوده. یعنی Jev دقیقاً یه trade-off بین دقت مطلق و سرعت/هزینه‌ست، نه لزوماً برتری مطلق توی همه‌ی سناریوها.

جمع‌بندی

استقبال از Jev اونقدر زیاد بوده که TypeSafe به‌طور موقت نتونسته جواب‌گوی حجم درخواست‌های API باشه، و پشتیبانی سریعش توسط پلتفرم‌هایی مثل ورسل و LiteLLM هم نشون میده صنعت این دسته از مدل («تصمیم‌گیرنده‌ی سریع» به‌جای «مولد متن») رو جدی گرفته. برای الان، Jev تقریباً تنها بازیگر شناخته‌شده توی این دسته‌ست، ولی با توجه به استقبالی که گرفته، بعیده رقبا خیلی طول بکشه تا وارد همین میدون بشن. اگه یه بخشی از سیستمت داره برای تصمیم‌های ساده و پرتکرار، پول یه LLM کامل رو میده، الان وقت خوبیه که Jev رو امتحان کنی.

این هفته یه استارتاپ کمتر شناخته‌شده به اسم TypeSafe AI یه مدل منتشر کرد که به‌جای رقابت توی همون مسیر همیشگی «مدل بزرگ‌تر، reasoning بهتر، context طولانی‌تر»، مسیر کاملاً متفاوتی رو انتخاب کرده. اسم این مدل Jev هست، و برخلاف تقریباً هر مدل دیگه‌ای که این روزها می‌بینیم، اصلاً یه LLM به معنای رایج کلمه نیست.

چی می‌سازتش خاص؟

بنیان‌گذار TypeSafe AI، دیه‌گو آلمیدا، قبلاً توی اوپن‌ای‌آی روی RLHF کار می‌کرده — همون فرآیندی که یه مدل زبانی خام رو به چیزی مثل ChatGPT تبدیل کرد. بعد از دو سال کار مخفیانه و جذب ۴۰ میلیون دلار سرمایه، حالا اولین محصول این شرکت رو معرفی کرده. ایده‌ی اصلی TypeSafe اینه که خیلی از کاربردهای هوش مصنوعی توی نرم‌افزار، اصلاً نیازی به یه پاراگراف متن ندارن؛ فقط یه بله/خیر، یه عدد، یا یه دسته‌بندی می‌خوان. برای همین Jev رو به‌عنوان چیزی که خودشون «System 1 Model» می‌نامنش معرفی کردن — اشاره‌ای به مفهوم تفکر سریع و کند دنیل کانمن.

فرق اصلیش با یه LLM معمولی اینجاست: یه LLM معمولی به‌صورت autoregressive کار می‌کنه، یعنی یه توکن تولید می‌کنه، بعد بر اساس همون توکن، توکن بعدی رو پیش‌بینی می‌کنه، و همین‌طور ادامه میده تا جمله کامل بشه. Jev کاملاً این چرخه رو کنار گذاشته: به‌جای تولید متن توکن‌به‌توکن، در یه پاس واحد یه تصمیم ساختاریافته برمی‌گردونه — یه احتمال، یه امتیاز اطمینان، یا یه مقدار typed.

مثال عملی: state، questions، و جواب typed

برای اینکه این تفاوت رو ملموس‌تر ببینی، بیا یه سناریوی واقعی رو با هم مرور کنیم: یه تیکت پشتیبانی که باید هم‌زمان مشخص بشه فوریه یا نه، شکایته یا نه، و باید به کدوم صف بره. به Jev یه «state» (متن یا دیتای زمینه) و یه مجموعه «questions» با نوع مشخص میدی — سه نوع اصلی که پشتیبانی می‌کنه Noul (بله/خیر با احتمال)، Choice (انتخاب از بین چند گزینه)، و Score (امتیاز روی یه معیار مرتب) هستن:

import { experimental_evaluate as evaluate } from 'ai';

const result = await evaluate({
  model: 'typesafe-ai/jev',
  state: 'دیروز دو بار ازم پول کم شده، همین امروز باید حلش کنین وگرنه اکانتمو می‌بندم.',
  questions: {
    is_urgent: {
      type: 'boolean',
      instructions: 'آیا این پیام فوریه؟',
    },
    queue: {
      type: 'choice',
      options: ['billing', 'technical', 'general'],
      instructions: 'این تیکت باید به کدوم صف بره؟',
    },
    frustration_level: {
      type: 'score',
      scale: [1, 5],
      instructions: 'سطح نارضایتی مشتری رو از ۱ تا ۵ بسنج.',
    },
  },
});

خروجی این فراخوانی، به‌جای یه پاراگراف توضیحی، یه شیء ساختاریافته با احتمال کنار هر جوابه، چیزی شبیه این:

{
  "answers": {
    "is_urgent": { "value": true, "probability": 0.94 },
    "queue": { "value": "billing", "probability": 0.88 },
    "frustration_level": { "value": 4, "probability": 0.81 }
  },
  "usage": { "input_tokens": 42, "output_tokens": 3 }
}

نکته‌ی مهم اینجا اینه که هر سه تا سؤال هم‌زمان و موازی ارزیابی شدن، نه به‌صورت سه فراخوانی جدا، و کد تو مستقیم می‌تونه روی is_urgent.value یا queue.value شرط بذاره — بدون parse کردن یه متن آزاد یا امیدوار بودن به اینکه مدل فرمت JSON رو درست رعایت کرده باشه. همین چیزیه که TypeSafe بهش میگه حذف مرحله‌ی «تولید متن غیرضروری».

چرا این‌قدر سریع و ارزونه؟

TypeSafe میگه معماری Jev، همراه با یه sampler موازی جدید و یه روش آموزشی به اسم Reinforcement Learning for Calibrated Decisions، باعث شده این مدل بتونه چند تا سؤال تعریف‌شده رو هم‌زمان ارزیابی کنه. ادعاهای این شرکت درباره‌ی سرعت و هزینه واقعاً چشمگیرن: طبق گزارش‌های خودشون، Jev تا ۱۹۳.۶ برابر سریع‌تر و تا ۴۴۴.۶ برابر ارزون‌تر از LLM های معمول روی ارزیابی‌های workflow عمل کرده. قیمت‌گذاریش هم غیرمعموله: ورودی به ازای هر میلیارد توکن (نه میلیون) حدود ۴۲ دلاره، در حالی که خروجی عملاً رایگانه — چون متن طولانی‌ای تولید نمیشه که بابتش هزینه بگیرن. یه نکته‌ی مهم دیگه اینه که چون خروجی‌ها از قبل محدود به یه فرمت مشخص هستن، طبق ادعای TypeSafe این مدل عملاً نمی‌تونه دچار hallucination بشه.

کجا استفاده میشه و اکوسیستمش چقدر جدیه؟

Jev قرار نیست جای ChatGPT رو بگیره؛ نمی‌تونه ایمیل بنویسه یا مکالمه کنه. جایی که معنا پیدا می‌کنه، داخل نقاط تصمیم‌گیری یه اپلیکیشنه: انتخاب ابزار یا subagent بعدی توی یه حلقه‌ی agent، تصمیم بین ادامه‌دادن/تلاش دوباره/پرسیدن از کاربر/توقف، امتیازدهی به فوریت یا ریسک قبل از یه اقدام، و راستی‌آزمایی خروجی یه مدل دیگه برای guardrail. طبق مستندات، محدودیتش اینه که فقط ورودی متنی می‌پذیره و سقف context اون ۳۲ هزار توکنه — یعنی برای دیتای خیلی حجیم مناسب نیست.

اکوسیستم دورش هم سریع شکل گرفته: Jev همین الان از طریق AI Gateway ورسل و AI SDK (با متد آزمایشی evaluate)، پلتفرم‌هایی مثل orq.ai و LiteLLM (به‌عنوان proxy)، و ابزار observability مثل Braintrust (برای ردیابی سؤال‌ها، جواب‌ها و توزیع احتمالات) در دسترسه. کتابخونه‌های رسمی پایتون و جاوااسکریپت وجود دارن، و حتی یه SDK غیررسمی راست هم توسط کامیونیتی نوشته شده. یه ریپازیتوری کامیونیتی هم به اسم awesome-jev-by-typesafe الگوها و نمونه‌کدهای مختلف استفاده از این مدل رو جمع کرده — نشونه‌ی اینکه توسعه‌دهنده‌ها خیلی سریع دارن دنبال جای مناسبش توی stack خودشون می‌گردن.

بررسی کامل: نقاط قوت و محدودیت‌ها

نقطه‌قوت اصلی Jev اینه که یه دسته از مسائل رو که همیشه با یه LLM معمولی حل می‌کردیم — دسته‌بندی، routing، امتیازدهی — رو ارزون‌تر، سریع‌تر و قابل‌اعتمادتر (از نظر فرمت خروجی) می‌کنه؛ دیگه لازم نیست نگران parse کردن یه JSON ناقص یا یه توضیح اضافه‌ی غیرمنتظره باشی. برگردوندن احتمال کنار هر جواب هم یه مزیت عملیه: می‌تونی موارد مطمئن رو خودکار پردازش کنی و فقط موارد مبهم رو برای بررسی انسانی نگه داری، الگویی که توی خیلی از نمونه‌کدهای منتشرشده هم دیده میشه.

از طرف دیگه، چند تا محدودیت هم داره که باید در نظرشون بگیری. اول، ورودی فقط متنیه، یعنی برای تصمیم‌گیری بر پایه‌ی تصویر یا صدا اصلاً گزینه نیست. دوم، سقف context ۳۲ هزار توکنی یعنی برای state های خیلی بزرگ (مثلاً یه سند طولانی) باید اول خلاصه‌سازی یا فیلتر انجام بدی. سوم، و شاید مهم‌تر از همه، ارقام چشمگیر سرعت و هزینه‌ای که TypeSafe منتشر کرده، بر پایه‌ی benchmark و روش ارزیابی خودشونه؛ یه مقایسه‌ی مستقل که یکی از کاربرها بین Jev و Gemini برای دسته‌بندی ایمیل انجام داده بود نشون داد Gemini کمی دقیق‌تر عمل کرده، هرچند ده تا بیست برابر گرون‌تر بوده. یعنی Jev دقیقاً یه trade-off بین دقت مطلق و سرعت/هزینه‌ست، نه لزوماً برتری مطلق توی همه‌ی سناریوها.

جمع‌بندی

استقبال از Jev اونقدر زیاد بوده که TypeSafe به‌طور موقت نتونسته جواب‌گوی حجم درخواست‌های API باشه، و پشتیبانی سریعش توسط پلتفرم‌هایی مثل ورسل و LiteLLM هم نشون میده صنعت این دسته از مدل («تصمیم‌گیرنده‌ی سریع» به‌جای «مولد متن») رو جدی گرفته. برای الان، Jev تقریباً تنها بازیگر شناخته‌شده توی این دسته‌ست، ولی با توجه به استقبالی که گرفته، بعیده رقبا خیلی طول بکشه تا وارد همین میدون بشن. اگه یه بخشی از سیستمت داره برای تصمیم‌های ساده و پرتکرار، پول یه LLM کامل رو میده، الان وقت خوبیه که Jev رو امتحان کنی.

هر دوی این ابزارها یه مشکل مشترک رو حل می‌کنن: خسته شدن از rate limit و جابه‌جایی دستی بین چند تا provider مدل زبانی. هر دو هم متن‌باز، رایگان، و زیر لایسنس MIT هستن، و هر دو یه endpoint سازگار با OpenAI رو رو localhost:20128/v1 بالا میارن (که خودش نشون می‌ده این دو تا از یه فضای مشترک الهام گرفتن یا حتی به هم مرتبطن). ولی از نظر دامنه‌ی قابلیت و بلوغ، تفاوت‌های واقعی دارن.

معرفی کوتاه هر کدوم

9Router رو یه توسعه‌دهنده به اسم decolua ساخته و تمرکزش دقیقاً رو یه مسئله‌ست: صرفه‌جویی توکن و جلوگیری از قطعی کار به‌خاطر rate limit، از طریق fallback سه‌لایه (اشتراک → API ارزون → provider رایگان). طبق آمار گیت‌هاب، این پروژه به بیش از ۲۰ هزار ستاره رسیده (منابع مختلف بین ۲۱۸۰۰ تا ۲۴۸۰۰ ستاره گزارش کردن، چون این عدد مدام در حال تغییره) و حدود ۳۶۰۰ فورک داره.

OmniRoute دامنه‌ی گسترده‌تری رو هدف گرفته؛ علاوه بر همون routing و fallback، خودش رو به‌عنوان یه پلتفرم کامل‌تر معرفی می‌کنه که MCP server، پروتکل A2A، حافظه‌ی مکالمه، و guardrail هم توش هست. طبق آمار خود پروژه، از فوریه‌ی ۲۰۲۶ شروع شده و الان حدود ۲۰ هزار ستاره و ۲۸۰۰ فورک داره؛ یعنی تقریباً هم‌سایز 9Router ولی با تاریخچه‌ی کوتاه‌تر و سرعت رشد بالاتر.

مقایسه‌ی مستقیم

نکته‌ی مهم درباره‌ی این جدول: بخش زیادیش (مخصوصاً اعداد OmniRoute) از صفحه‌ی مقایسه‌ی رسمی خود سایت OmniRoute اومده، که طبیعتاً به نفع خودشه. برای همین اعداد 9Router رو از منابع مستقل (Medium، AIMojo، EveryDev.ai، NGJOO) کراس‌چک کردم تا تصویر متوازن‌تری داشته باشیم، ولی بازم توصیه می‌شه قبل از تصمیم نهایی، خودت این دو تا رو مستقیم امتحان کنی.

کجا هرکدوم برنده‌ست

9Router برای سادگی و تمرکز: اگه فقط می‌خوای مشکل rate limit حل بشه و یه ابزار سبک، ساده، و بدون قابلیت‌های اضافه‌ی پیچیده می‌خوای، 9Router دقیقاً همین رو ارائه می‌ده. سطح پیچیدگیش کمتره و برای شروع سریع مناسب‌تره.

OmniRoute برای دامنه‌ی وسیع‌تر: اگه علاوه بر routing، به قابلیت‌هایی مثل MCP server (که خود gateway رو به یه ابزار قابل‌کنترل توسط agent تبدیل می‌کنه)، A2A، یا حافظه‌ی مکالمه هم نیاز داری، OmniRoute دامنه‌ی گسترده‌تری داره. تعداد provider هاش هم به‌طور محسوسی بیشتره (۳۳۹ در مقابل حدود ۴۰ تا ۶۰).

نکته‌ی مشترک قبل از استفاده‌ی جدی

هر دو ابزار، صرف‌نظر از این‌که کدومش رو انتخاب کنی، یه ویژگی مشترک مهم دارن که باید بهش توجه کنی: مسیر کردن ترافیک از طریق این gateway ها، پردازش یا شرایط استفاده‌ی provider اصلی (مثل اوپن‌ای‌آی یا آنتروپیک) رو حذف نمی‌کنه؛ فقط یه لایه‌ی اضافه بین تو و اون provider اضافه می‌کنن. همچنین، هر دو تبدیل به یه نقطه‌ی حیاتی تو مسیر درخواست‌هات می‌شن؛ اگه gateway از کار بیفته یا تنظیماتش خراب بشه، همه‌ی ابزارهایی که ازش عبور می‌کنن تحت تأثیر قرار می‌گیرن. برای استفاده‌ی جدی یا تیمی، حتماً به فکر بک‌آپ تنظیمات و یه plan B (برگشت مستقیم به provider اصلی در صورت قطعی gateway) باش.

جمع‌بندی

اگه اولویتت سادگی و یه راه‌حل تمرکزیافته برای مشکل rate limit است، 9Router انتخاب سبک‌تری‌یه. اگه دنبال یه پلتفرم کامل‌تر با تعداد provider بیشتر و قابلیت‌های اضافه مثل MCP و A2A هستی، و راحتی با پیچیدگی بیشتر مشکلی نداری، OmniRoute گزینه‌ی جامع‌تریه. چون هر دو رایگان و متن‌بازن، عملاً هیچ هزینه‌ای برای امتحان کردن هر دوشون و دیدن این‌که کدوم با workflow خودت بهتر جفت می‌شه نداری.

اگه از چند تا ابزار agentic (Claude Code، Cursor، Codex، Cline) هم‌زمان استفاده می‌کنی و خسته شدی از این‌که هر کدوم rate limit جدا داره، یا هر وقت quota یکی تموم می‌شه مجبوری دستی سوییچ کنی، OmniRoute دقیقاً برای همین مشکل ساخته شده. این یه AI gateway متن‌باز و local-first است که همه‌ی provider های مختلف (اوپن‌ای‌آی، آنتروپیک، گوگل، دیپ‌سیک و خیلی‌های دیگه) رو پشت یه endpoint واحد و سازگار با API اوپن‌ای‌آی جمع می‌کنه.

چیه دقیقاً و چطور کار می‌کنه

به‌جای این‌که هر ابزار کدنویسیت رو جدا به هر provider وصل کنی، فقط یه بار base URL ابزارت (مثلاً Claude Code یا Cursor) رو به یه آدرس local (پیش‌فرض localhost:20128/v1) اشاره می‌دی. OmniRoute پشت این آدرس، درخواست رو می‌گیره، بر اساس قوانین routing که خودت تعریف کردی (یا حالت auto) تصمیم می‌گیره کدوم provider جواب بده، و پاسخ رو به فرمتی که ابزارت انتظار داره (چه فرمت OpenAI، چه Claude، چه Gemini) برمی‌گردونه.

نصبش هم ساده‌ست:

npm install -g omniroute
omniroute

بعد از اجرا، هم API و هم یه داشبورد وب رو همون پورت ۲۰۱۲۸ بالا میان.

عدد و رقم‌های پروژه

طبق آمار رسمی خود پروژه، OmniRoute از ۱۳ فوریه‌ی ۲۰۲۶ (کمتر از چهار ماه پیش) شروع به کار کرده و در همین مدت کوتاه به بیش از ۲۰ هزار ستاره‌ی گیت‌هاب، حدود ۲۸۰۰ فورک، و مشارکت بیش از ۳۵۰ توسعه‌دهنده رسیده؛ با ۲۷۱ نسخه‌ی منتشرشده و بیش از ۴۰۰۰ pull request مرج‌شده. کل پروژه زیر لایسنس MIT هست، یعنی کاملاً متن‌باز و بدون محدودیت استفاده‌ی تجاری.

قابلیت‌های اصلی

Auto-fallback چندلایه: اگه یه provider به rate limit بخوره یا quota ش تموم بشه، OmniRoute تو چند میلی‌ثانیه، بدون این‌که کارت متوقف بشه، به provider بعدی سوییچ می‌کنه. این fallback سه‌لایه‌ست (سطح provider، سطح connection/کلید، سطح مدل)، یعنی یه کلید API خراب کل provider رو از کار نمی‌ندازه.

۱۷ استراتژی routing: از «اول رایگان‌ها رو مصرف کن» گرفته تا «همیشه ارزون‌ترین گزینه» یا «بار رو بین چند کلید پخش کن»، می‌شه دقیقاً مشخص کرد اولویت routing بر چه اساسی باشه.

فشرده‌سازی توکن: با ترکیب چند تا موتور فشرده‌سازی (که خودشون بهش می‌گن RTK و Caveman)، خروجی ابزارها و context تکراری رو قبل از رسیدن به مدل فشرده می‌کنه؛ طبق ادعای پروژه، بین ۱۵ تا ۹۵ درصد صرفه‌جویی تو مصرف توکن، بسته به نوع کار.

استفاده از quota رایگان: پروژه ادعا می‌کنه بیش از ۹۰ provider با پلن رایگان رو ردیابی می‌کنه و مصرف رایگان رو به‌صورت pool-deduped (بدون شمارش تکراری) جمع می‌زنه؛ رقمی که خودشون حدود ۱.۵ میلیارد توکن رایگان در ماه اعلام می‌کنن.

پشتیبانی از MCP و A2A: خود gateway به‌عنوان یه سرور MCP هم عمل می‌کنه (بیش از ۱۰۰ ابزار در قالب چند ده scope)، و از پروتکل A2A هم پشتیبانی می‌کنه؛ یعنی یه agent می‌تونه مستقیم خود OmniRoute رو به‌عنوان یه ابزار کنترل کنه، نه فقط ازش عبور کنه.

نکته‌ی مهم قبل از استفاده‌ی جدی

قبل از این‌که این ابزار رو رو یه workflow حساس یا production تکیه بدی، چند تا نکته رو باید در نظر بگیری. اول، مسیر کردن ترافیک از طریق gateway خودت، پردازش، شرایط استفاده، یا نگه‌داری داده‌ی provider اصلی رو حذف نمی‌کنه؛ داده‌ت هنوز به همون provider (مثلاً OpenAI یا آنتروپیک) می‌رسه، فقط از یه لایه‌ی اضافه عبور کرده. دوم، این ابزار خودش یه نقطه‌ی حیاتی تو مسیر درخواست‌هات می‌شه؛ اگه down بشه، تنظیماتش خراب بشه، یا دیتابیس local ش (SQLite) کرش کنه، همه‌ی ابزارهایی که ازش عبور می‌کنن تحت تأثیر قرار می‌گیرن. برای همین، برای استفاده‌ی جدی، حتماً باید persistence، بک‌آپ، و کنترل دسترسی مناسب رو خودت تنظیم کنی.

یه نکته‌ی دیگه هم اینه که چون این پروژه خیلی تازه و به‌شدت پرتغییره (۲۷۱ نسخه تو کمتر از چهار ماه)، بهتره قبل از هر آپدیت، یه نسخه‌ی مشخص رو pin کنی و رفتار ابزارهای کدنویسیت رو (streaming، tool call، context طولانی) بعد از هر آپدیت جدا تست کنی، نه این‌که فقط بر اساس لیست مدل‌ها قضاوت کنی که همه‌چیز درست کار می‌کنه.

جمع‌بندی

اگه خسته شدی از مدیریت دستی چند تا کلید API و برخورد مکرر با rate limit وسط کار، OmniRoute یه راه‌حل عملی و رایگانه که با یه دستور نصب می‌شه و تقریباً با هر ابزار agentic معروفی (Claude Code، Cursor، Codex، Cline، Copilot) سازگاره. ولی برای پروژه‌های production یا تیمی، بهتره اول یه دوره‌ی ارزیابی جدی (تست کیفیت پاسخ، latency، failover واقعی) قبل از تکیه‌ی کامل روش انجام بدی؛ چون production-ready بودن این ابزار، بیشتر به تنظیمات و تست‌های خودت بستگی داره تا صرفاً نصب و راه‌اندازیش.