تصور کنید توسعهدهندهی پایتون باشید و بتوانید اپلیکیشنهای آمادهی تولید (Production-ready) خود را بدون نوشتن حتی یک خط کد جاوااسکریپت، روی یک شبکهی جهانی توزیع کنید. این رویای برنامهنویسان در ۲۱ سپتامبر ۲۰۲۶ با اعلام عرضه عمومی (GA) قابلیت Python Workers توسط کلودفلر (Cloudflare) به واقعیت تبدیل شد. این اتفاق پایتون را به یک زبان درجهیک در پلتفرم توسعهدهندگان کلودفلر تبدیل میکند.
سالها بود که دنیای رایانش لبه (Edge Computing) — شبیه به داشتن چندین شعبهی کوچک از یک فروشگاه در تمام محلههای شهر برای دسترسی سریعتر مشتریان — در تسلط جاوااسکریپت و تایپاسکریپت بود. در حالی که پایتون پادشاه بلامنازع هوش مصنوعی و علوم داده است، اما نیازهای زماناجرایی (Runtime) آن، استقرار در محیطهای سبک و ایزولهای که برای توابع سرورلس لبه مورد نیاز است را دشوار میکرد. کلودفلر این مشکل را با استفاده از یک مفسر پایتون کامپایلشده با وباسمبلی (WebAssembly) از طریق Pyodide حل کرد تا کدها در محیط Workers اجرا شوند. این رویکرد از این واقعیت بهره میبرد که Workers از سال ۲۰۱۸ از وباسمبلی پشتیبانی کرده است و محیطی ایدهآل برای یک مفسر کامپایلشده با Wasm فراهم میکند.
یکپارچگی بومی و پشتیبانی از فریمورکها
عرضهی عمومی (GA) باعث حذف «کدهای چسب» (Glue Code) شد که پیش از این توسعهدهندگان پایتون را آزار میداد. در فاز بتا، استفاده از Bindingهای کلودفلر مستلزم تبدیل صریح اشیاء پایتون به اشیاء تایپاسکریپت در مرز RPC بود. برای مثال، ارسال یک دیکشنری پایتون به یک صف (Cloudflare Queue) نیازمند استفاده از pyodide.ffi.to_js و js.Object.fromEntries بود تا اطمینان حاصل شود که دادهها با محیط جاوااسکریپت سازگار هستند. این موضوع منبع اصلی خطاهای انسانی و خطاهای مدلهای هوش مصنوعی بود.
اکنون در نسخهی نهایی، تمام فرآیند تبدیل نوع دادهها در دل زماناجرا و SDK پایتون نهفته است. این امر به توسعهدهندگان اجازه میدهد تا از تمام Bindingهای کلودفلر به روشی پایتونیک (Pythonic) استفاده کنند. به نقل از مستندات کلودفلر، حالا یک فراخوانی ساده مثل self.env.QUEUE.send({"key": "value"}) بدون هیچ تبدیل دستی کار میکند. این اتصال یکپارچه به کل پلتفرم گسترش مییابد، از جمله Workers AI، R2، D1، Hyperdrive، Durable Objects، Queues و Workflows.

کلودفلر همچنین رابطهای داخلی (Connectors) برای فریمورکهای محبوب وب معرفی کرده است. حالا توسعهدهندگان میتوانند FastAPI، Django و Flask را با استفاده از بستههای workers.asgi یا workers.wsgi اجرا کنند. این رابطها مانند یک پل نازک عمل میکنند و درخواستهای بومی جاوااسکریپت را به ساختارهای استانداردی تبدیل میکنند که فریمورکهای پایتونی انتظار دارند.
مکانیسم عملکرد رابطهای فریمورک
پایتون از قراردادهای استانداردی برای ارتباطات وب استفاده میکند: رابط درگاه سرور وب (WSGI) برای اپلیکیشنهای همگام (Synchronous) و رابط درگاه سرور ناهمگام (ASGI) برای اپلیکیشنهای مدرن async. در استقرارهای سنتی، سرورهایی مثل Uvicorn یا Gunicorn اتصالات همزمان و Threadها را برای مقیاسبندی ترافیک مدیریت میکنند.
در Python Workers، خودِ پلتفرم Workers به عنوان سرور وب عمل میکند. از آنجایی که شبکه جهانی لبه، توازن بار (Load Balancing) و مقیاسپذیری نامحدود را مدیریت میکند، دیگر نیازی به اجرای یک سرور مجزا در داخل Worker نیست. رابطهای workers.asgi و workers.wsgi صرفاً پاسخ را با کمترین سربار (Overhead) بازمیگردانند. این موضوع اجازه میدهد هر فریمورکی که از این رابطها پیروی کند، قابل استقرار باشد. برای مثال، یک اپلیکیشن FastAPI را میتوان تنها با افزودن Default = asgi.entrypoint(app) به کد، مستقر کرد.

شکستن سد سوکتها
یکی از بزرگترین موانع فنی، نبود پشتیبانی از سوکتهای TCP در وباسمبلی بود. درایورهای استاندارد پایگاهداده پایتون، مانند aiomysql یا asyncpg برای برقراری اتصال به ماژول socket در کتابخانه استاندارد تکیه دارند. در یک محیط استاندارد، این ماژول فراخوانهای سیستمی POSIX را به سیستمعامل ارسال میکند. اما در یک سندباکس وباسمبلی، این فراخوانهای شبکه POSIX معمولاً توابع توخالی (Stubs) هستند که همیشه با شکست مواجه میشوند.
کلودفلر این سد را با پیادهسازی فراخوانهای سیستمی سوکت از طریق API اتصال Workers شکست. بر اساس بررسیهای فنی، وقتی یک درایور دیتابیس سعی میکند اتصالی TCP برقرار کند، این درخواست از طریق یک پیادهسازی سفارشی از syscall سوکت عبور میکند که عملیات پایتون را به فراخوانهای جاوااسکریپت متناظر در زماناجرای Workers ترجمه میکند. چون این اتفاق در سطح فراخوان سیستمی رخ میدهد، درایورهای دیتابیس نیازی به تغییر کد ندارند.
این پل ارتباطی اجازه میدهد Python Workers مستقیماً با Hyperdrive (سرویس شتابدهی دیتابیس کلودفلر) برای PostgreSQL و MySQL یکپارچه شوند. برای پیادهسازی این مورد، توسعهدهندگان یک binding به تنظیمات Wrangler خود اضافه میکنند (مثلاً "hyperdrive": [ { "binding": "HYPERDRIVE_MYSQL", "id": "<example id>" } ]) و سپس از درایورهای آشنایی مثل aiomysql برای اتصال با استفاده از hd.host ،hd.port ،hd.user و hd.password استفاده میکنند.

گسترش اکوسیستم Wasm
از آنجایی که Python Workers در یک سندباکس Wasm اجرا میشوند، هر بستهای که دارای افزونههای بومی C/C++/Rust باشد، باید برای وباسمبلی cross-compile شود. پیش از این، روش استانداردی برای این کار وجود نداشت و تیم کلودفلر مجبور بود بستههای سفارشی را بهصورت دستی کامپایل و میزبانی کند که این امر اکوسیستم کتابخانههای موجود را بهشدت محدود میکرد.
برای ایجاد یک اکوسیستم پایدار که به نفع کل جامعهی پایتون روی وباسمبلی باشد، کلودفلر چندین گام استراتژیکی برداشت:
- PEP 783: کلودفلر این PEP را برای استانداردسازی PyEmscripten (پلتفرمی برای اجرای پایتون در زماناجرای مرورگر) پیشنهاد داد. پس از بیش از یک سال اصلاحات، این پیشنهاد پذیرفته شد. این امر به نگهدارندگان بستهها اجازه میدهد تا بستههای خود را برای پلتفرم PyEmscripten در تمام محیطهای سازگار بسازند و منتشر کنند.
- تثبیت زنجیره ابزار (Toolchain): آنها زنجیره ساخت Pyodide را تثبیت کردند تا برای تمام نگهدارندگان بستهها در دسترس باشد و ساخت بستهها برای پلتفرم PyEmscripten آسانتر شود.
- پشتیبانی از cibuildwheel: پشتیبانی از پلتفرم PyEmscripten به
cibuildwheelاضافه شد تا فرآیند پذیرش برای توسعهدهندگان ساده شود.
کلودفلر اکنون بهطور فعال با نگهدارندگان اصلی بستهها برای افزودن بیلدهای PyEmscripten همکاری میکند. آنها همچنین این تلاشها را در کنفرانس EuroPython ۲۰۲۶ در سخنرانی با عنوان «پایتون در همه جا: وضعیت پایتون روی وباسمبلی» ارائه کردند.
عاملهای هوش مصنوعی و خط لولهها (Pipelines)
سلطهی پایتون در هوش مصنوعی اکنون بهطور کامل در لبه به کار گرفته شده است. پیش از این، کتابخانههایی مثل LangChain و OpenAI شکست میخوردند زیرا کلاینتهای HTTP آنها (مانند requests یا httpx) به عملیات سطح پایین سوکت تکیه داشتند که در Python Workers موجود نبود.
کلودفلر تغییراتی را در کدهای منبع (Upstream) اعمال کرد تا اطمینان حاصل شود که این کلاینتهای HTTP میتوانند درخواستها را مستقیماً از طریق API fetch جاوااسکریپت در محیطهای وباسمبلی ارسال کنند. در ترکیب با پشتیبانی جدید از سوکت، اکنون کل پشتهی شبکه بهطور یکپارچه کار میکند.
در نتیجه، توسعهدهندگان میتوانند کتابخانههای هوش مصنوعی مانند openai ،langchain و mcp را بهصورت بومی اجرا کنند. اینها را میتوان با Workers AI برای استنتاج GPU سرورلس (با استفاده از مدلهایی مانند @cf/meta/llama-3.3-70b-instruct-fp8-fast) ترکیب کرد یا از طریق Cloudflare AI Gateway پروکسی کرد. این قابلیتها در کنار پیشرفتهای اخیر در مدیریت زیرساخت، مانند رویکرد OpenAI در اتوماسیون ارکستراسیون عاملها، مسیر توسعهی سیستمهای هوشمند را هموارتر میکند. برای مثال، با استفاده از بستهی langchain-cloudflare ،توسعهدهندگان میتوانند زنجیرههایی ایجاد کنند که PromptTemplate ،ChatCloudflareWorkersAI و StrOutputParser را برای تولید پاسخهای هوش مصنوعی در لبه ترکیب میکند.

الگوهای آماده برای تولید (Production-Ready)
کلودفلر یک مخزن به نام python-workers-examples فراهم کرده است که شامل چندین معماری مرجع برای نمایش قدرت نسخهی GA است:
ارکستراسیون هوش مصنوعی و دادهها:
- ارکستراسیون ناهمگام AI: یک ژنراتور تصویر-به-تصویر فولاستک. این سیستم درخواستها را میپذیرد، آنها را در یک Cloudflare Queue قرار میدهد، از Workflows برای مدیریت تولید تصویر از طریق Workers AI استفاده میکند و تصویر نهایی را در یک باکت R2 ذخیره میکند.
- سیستمهای RAG: پیادهسازی تولید بازیابیافزا (Retrieval-Augmented Generation) با استفاده از Workers AI و Vectorize (دیتابیس برداری کلودفلر). این سیستمها زمانی بیشترین کارایی را دارند که با مدلهای پیشرفتهای ترکیب شوند؛ برای نمونه، مدل GPT-6 Astra با نرخ موفقیت بالای ۷۲٪ در وظایف پیچیده استانداردهای جدیدی را برای تعامل با سیستمعاملها تعریف کرده است.
سرویسهای بلادرنگ و لبه:
- پردازش Jetstream بلوسکای (Bluesky): یک Python Worker که به WebSocketهای ATProto/Bluesky Jetstream متصل میشود. با استفاده از یک Durable Object برای پشتیبانی از اتصال، Worker وضعیت طولانیمدت را برای زنده نگه داشتن WebSocket حفظ میکند.
- سرورهای MCP: ساخت و استقرار سرورهای Model Context Protocol (MCP) با استفاده از بستهی رسمی پایتون MCP برای فراهم کردن دسترسی دستیارهای هوش مصنوعی به دادههای لبه.
- ورکرهای پویا (Dynamic Workers): قابلیت ایجاد یک Python Worker در داخل یک Worker دیگر با استفاده از Dynamic Workers.

یکپارچگی در سراسر پلتفرم
کلودفلر متعهد شده است که پایتون را به عنوان یک زبان اصلی در تمام تجربهی توسعهدهندگان خود قرار دهد. این شامل بهروزرسانی مستندات در تمام محصولات برای گنجاندن کدهای نمونهی پایتون است. در بیشتر موارد، هر جا که نمونهای به زبان تایپاسکریپت وجود دارد، اکنون معادل پایتونی آن نیز در دسترس است. توسعهدهندگان میتوانند قطعات کد را بین جاوااسکریپت، تایپاسکریپت و پایتون در سراسر مستندات تغییر دهند.
این تغییر به این معناست که توسعهدهندگان پایتون دیگر مجبور نیستند بین اکوسیستم غنی کتابخانههای پایتون و مقیاسپذیری لبه یکی را انتخاب کنند. با انتزاع زیرساخت، کلودفلر بهطور موثری شبکه جهانی خود را به یک محیط اجرای پایتون توزیعشده و عظیم تبدیل کرده است.
برای یک توسعهدهنده معمولی، این امر «راهاندازی سرد» (Cold Start) و اضطراب پیکربندی مرتبط با استقرارهای سنتی پایتون را از بین میبرد. اکنون میتوانید در عرض چند دقیقه از یک پروتوتایپ FastAPI محلی به یک API توزیعشده در سطح جهانی برسید.
چشمانداز آینده
رسیدن به مرحلهی GA تنها اولین قدم است. نقشهی راه کلودفلر شامل بهینهتر کردن مصرف حافظه در Python Workers و افزایش عملکرد کلی است. آنها همچنین به گسترش تعداد بستههای پشتیبانیشده ادامه میدهند. هدف نهایی این است که هر بستهی پایتون در نهایت دارای یک wheel باشد که با وباسمبلی کار کند و بدین ترتیب تمام قدرت اکوسیستم پایتون در لبه در دسترس باشد.
گام بعدی شما
- اگر از FastAPI استفاده میکنید، کد خود را با بستهی
workers.asgiتست کنید تا سرعت پاسخدهی در مناطق مختلف جهان را بسنجید. - برای کاهش هزینههای استنتاج، زنجیرههای LangChain خود را مستقیماً روی Workers AI منتقل کنید.
- مخزن
python-workers-examplesرا برای پیادهسازی سیستمهای RAG در لبه بررسی کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.




گفتگو