کلودفلر پایتون ورکرز را عمومی کرد؛ FastAPI، Django و Hyperdrive

شرکت کلودفلر (Cloudflare) در ۲۱ سپتامبر ۲۰۲۶ اعلام کرد که پایتون ورکرز (Python Workers) به وضعیت دسترس‌پذیری عمومی رسیده‌است. به گفتهٔ نویسندگان این اعلامیه در وبلاگ رسمی شرکت، هدف از این مسیر آن بوده‌است که نوشتن ورکر به زبان پایتون به‌سادگی تایپ‌اسکریپت باشد و اکوسیستم بسته‌ها و فریم‌ورک‌های پایتون «فقط کار کند».

معنای GA در این اعلامیه این است که پایتون اکنون زبانی درجه‌یک و کاملاً پشتیبانی‌شده روی پلتفرم توسعه‌دهندگان کلودفلر است. توسعه‌دهندگان می‌توانند کد، کتابخانه و الگوهای طراحی آشنای پایتون را بیاورند و آن را به Workers AI، R2، D۱، Hyperdrive، Durable Objects، Queues، Workflows و سایر بخش‌های پلتفرم متصل کنند. امکان اجرای فریم‌ورک‌هایی مانند FastAPI، Django و Flask نیز اعلام شده‌است؛ حتی می‌توان با Dynamic Workers یک پایتون ورکر را از داخل ورکر دیگری ساخت.

کلودفلر دو سال پیش پایتون ورکرز را معرفی کرد تا برنامه‌های پایتون روی زمان‌اجرای Workers اجرا شوند. از سال ۲۰۱۸ پشتیبانی از WebAssembly در Workers زمینهٔ اجرای مفسر پایتون کامپایل‌شده به Wasm را فراهم کرده‌بود و با استفاده از Pyodide طیف گسترده‌ای از برنامه‌ها پوشش داده شد. ویژگی‌های برجسته‌شده در این اعلامیه نتیجهٔ همین تلاش چندساله دانسته شده‌اند و اکنون برای تولید در دسترس همه اعلام شده‌اند.

پیش‌تر، استفاده از بایندینگ‌های کلودفلر در پایتون ورکرز نیازمند تبدیل صریح اشیاء پایتون به اشیاء تایپ‌اسکریپت در مرز RPC بود؛ برای نمونه ارسال دیکشنری به Queue با تبدیل دستی از طریق to_js انجام می‌شد. بنا بر اعلام شرکت، کل فرایند تبدیل نوع اکنون داخل زمان‌اجرای Workers و SDK پایتون کپسوله شده‌است و می‌توان بدون نوشتن جاوااسکریپت، بایندینگ‌ها را به سبک پایتونیک فراخوانی کرد.

اگر تجربهٔ استقرار API یا پایپ‌لاین هوش مصنوعی روی لبهٔ شبکه با پایتون داشته‌اید، دیدگاه خود را در بخش دیدگاه‌ها بنویسید.

برای اجرای سرور API می‌توان از فریم‌ورک‌های رایج پایتون استفاده کرد. کلودفلر اتصال‌دهنده‌ای داخلی ارائه کرده‌است که برنامه را به پایتون ورکرز وصل می‌کند. در محیط‌های بومی معمولاً از uvicorn برای اجرای FastAPI استفاده می‌شود؛ در پایتون ورکرز همان برنامه با بستهٔ workers.asgi و یک قطعه کد کوتاه اجرا می‌شود. برای برنامه‌های همگام مانند Django نیز بستهٔ workers.wsgi معرفی شده‌است.

پایتون قرارداد استانداردی برای ارتباط برنامه و سرور وب دارد: WSGI و نسخهٔ ناهمگام آن ASGI. در Workers، خود پلتفرم نقش سرور وب را ایفا می‌کند و مقیاس‌پذیری را شبکهٔ سراسری بر عهده می‌گیرد. اتصال‌دهنده‌های asgi و wsgi درخواست جاوااسکریپت بومی را به ساختارهای WSGI/ASGI ترجمه می‌کنند و پاسخ را با سربار کم بازمی‌گردانند. این اتصال‌دهنده‌ها با هر فریم‌ورک پایتونی سازگار با WSGI یا ASGI قابل استفاده‌اند.

ادغام Hyperdrive با پایتون ورکرز برای PostgreSQL و MySQL اعلام شده‌است. پیش‌تر نبود پشتیبانی از سوکت TCP مانع از کار درایورهایی مانند aiomysql یا asyncpg بود. کلودفلر اعلام کرده‌است که فراخوان‌های سیستمی سوکت را با API اتصال Workers پیاده‌سازی کرده‌است تا عملیات شبکه‌ای به فراخوان‌های جاوااسکریپت زمان‌اجرا ترجمه شوند. پس از پیکربندی بایندینگ در Wrangler، اتصال با درایورهای آشنا امکان‌پذیر اعلام شده‌است.

چون پایتون ورکرز داخل سندباکس Wasm اجرا می‌شوند، بسته‌های دارای افزونهٔ بومی باید به WebAssembly کراس‌کامپایل شوند. شرکت پیشنهاد PEP ۷۸۳ را برای استانداردسازی پلتفرم PyEmscripten مطرح کرد که پس از بیش از یک سال بحث پذیرفته شد. زنجیرهٔ ساخت Pyodide نیز پایدار شد و پشتیبانی PyEmscripten به cibuildwheel افزوده شد.

برای عامل‌ها و پایپ‌لاین‌های هوش مصنوعی، کتابخانه‌هایی مانند openai، langchain و mcp با هدایت درخواست‌ها از طریق fetch جاوااسکریپت در محیط Wasm قابل اجرا اعلام شده‌اند. ترکیب این قابلیت با Workers AI و AI Gateway نیز آمده‌است؛ از جمله بستهٔ langchain-cloudflare. الگوهای نمونه در مخزن python-workers-examples شامل هماهنگی تولید تصویر با Queue و Workflows و پردازش جریان WebSocket با Durable Object است.

آیا عمومی‌شدن پایتون ورکرز مسیر استقرار برنامه‌های پایتون روی لبه را برای تیم شما تغییر می‌دهد؟