خرید پروژه‌ی متن‌باز Arroyo توسط Cloudflare 🔥
شرکت Cloudflare به‌تازگی اعلام کرده که پروژه‌ی Arroyo، یکی از نوآورانه‌ترین موتورهای پردازش جریان داده، را به مجموعه‌ی خود افزوده است. این پروژه که در سال ۲۰۲۲ با زبان #Rust 🦀 و توسط دو بنیان‌گذار راه‌اندازی شد، بر تجربه‌ای بی‌نیاز از مدیریت زیرساخت، عملکرد بالا و سادگی در توسعه متمرکز بوده است.
منبع خبر : https://www.arroyo.dev/blog/arroyo-is-joining-cloudflare
🔍 کتابخانه Arroyo : ساده‌سازی پردازش جریان بلادرنگ برای همه ⚙️
پروژه Arroyo یک موتور پردازش جریان (#StreamProcessing) مدرن و متن‌باز است که با هدفی روشن توسعه یافته:
💡 «تبدیل پردازش جریان از یک فناوری پیچیده و لوکس به ابزاری ساده و در دسترس، شبیه نوشتن یک کوئری SQL معمولی برای یک جدول پایگاه‌داده.»
این پروژه با هدف ساده‌سازی توسعه‌ی سیستم‌های پردازش آنی و حذف پیچیدگی‌های زیرساختی ایجاد شده ⚡️ و از فناوری‌های مدرنی مانند Apache Arrow 🏹 و DataFusion 🔗 بهره می‌برد تا عملکرد بالا و کارایی حافظه را تضمین کند.
✨ مهم‌ترین قابلیت‌های Arroyo:
✅ پشتیبانی کامل از SQL با بیش از ۳۰۰ تابع توکار برای تحلیل‌های زمانی، پنجره‌ای و آماری
✅ دقت بالا با Exactly-Once Semantics حتی در صورت بروز خطا یا دریافت داده‌های نامرتب
✅ پشتیبانی از انواع پنجره‌ها (گروه‌بندی زمانی رخدادها): sliding، tumbling و session ⏱️
✅ اتصال به منابع متنوع مانند #Kafka 🧩، #Redis 🔴، #RabbitMQ 🐰 و CDC
✅ مقیاس‌پذیری برای پردازش میلیون‌ها رویداد در ثانیه ⚡️
✅ پشتیبانی از UDF با #Python 🐍، پروتکل Protobuf و مدیریت TTL در وضعیت‌ها
✅ امکان ساخت lookup tables برای داده‌های جریانی 🧷
📸 برای اینکه دقیقا متوجه شوید منظور از پردازش جریان با Arroyo آنهم فقط به کمک SQL چیست، می‌توانید به عکس‌های پایین این پست دقت کنید.
اکنون با پیوستن Arroyo به زیرساخت گسترده‌ی Cloudflare، کاربران می‌توانند از مزایای ترکیب پردازش آنی SQL (به کمک Arroyo)، ذخیره‌سازی ابری (R2)، صف‌های توزیع‌شده (Queues) و اجرای بدون سرور (Workers) در قالب یک پلتفرم یکپارچه و مقیاس‌پذیر بهره‌مند شوند.
🔓کتابخانه Arroyo همچنان متن‌باز و قابل میزبانی مستقل باقی خواهد ماند، و با حمایت Cloudflare از توسعه‌ی پایدار، افزایش کارایی و رشد جامعه‌ی کاربران خود بهره‌مند خواهد شد.
🚀 برای مهندسان داده، استارتاپ‌ها، مدیران محصول، تحلیل‌گران داده و تیم‌هایی که به‌دنبال جایگزینی سریع‌تر و ساده‌تر برای #ApacheFlink یا سایر ابزارهای پردازش جریان هستند، Arroyo اکنون نه‌تنها یک انتخاب هوشمندانه، بلکه یک بستر قدرتمند برای آینده است.
🦀 همچنین Arroyo نمونه‌ای از موج نوین پروژه‌های مبتنی بر زبان برنامه‌نویسی Rust است؛ زبانی که با امنیت بالا و مدیریت حافظه‌ی بسیار دقیق، در حال گشودن مرزهای تازه‌ای در دنیای زیرساخت‌های داده و پردازش بلادرنگ است.
شرکت Cloudflare به‌تازگی اعلام کرده که پروژه‌ی Arroyo، یکی از نوآورانه‌ترین موتورهای پردازش جریان داده، را به مجموعه‌ی خود افزوده است. این پروژه که در سال ۲۰۲۲ با زبان #Rust 🦀 و توسط دو بنیان‌گذار راه‌اندازی شد، بر تجربه‌ای بی‌نیاز از مدیریت زیرساخت، عملکرد بالا و سادگی در توسعه متمرکز بوده است.
منبع خبر : https://www.arroyo.dev/blog/arroyo-is-joining-cloudflare
این خرید از دو جهت برای من مهم است:جزییات این خبر و این پروژه را با هم کمی مرور می‌کنیم.
🧠 کلودفلیر با افزودن قابلیت پردازش جریان با SQL 📊 به سرویس‌هایی مثل R2 ، Workers ⚙️ و Queues ، یک گام مهم به‌سوی ساخت پلتفرم ابری کامل، مقیاس‌پذیر و بی‌نیاز از مدیریت زیرساخت برداشته است—رقابتی جدی برای #AWS و #GoogleCloud.
🧠 پروژه‌ی متن‌باز Arroyo تنها با تلاش دو نفر در ۲۰۲۲ آغاز شد و امروز توسط یکی از بزرگ‌ترین شرکت‌های اینترنتی خریداری شده است؛ نمونه‌ای الهام‌بخش از اینکه تیم‌های کوچک هم می‌توانند به موفقیت‌های بزرگ برسند. 🚀
🔍 کتابخانه Arroyo : ساده‌سازی پردازش جریان بلادرنگ برای همه ⚙️
پروژه Arroyo یک موتور پردازش جریان (#StreamProcessing) مدرن و متن‌باز است که با هدفی روشن توسعه یافته:
💡 «تبدیل پردازش جریان از یک فناوری پیچیده و لوکس به ابزاری ساده و در دسترس، شبیه نوشتن یک کوئری SQL معمولی برای یک جدول پایگاه‌داده.»
این پروژه با هدف ساده‌سازی توسعه‌ی سیستم‌های پردازش آنی و حذف پیچیدگی‌های زیرساختی ایجاد شده ⚡️ و از فناوری‌های مدرنی مانند Apache Arrow 🏹 و DataFusion 🔗 بهره می‌برد تا عملکرد بالا و کارایی حافظه را تضمین کند.
✨ مهم‌ترین قابلیت‌های Arroyo:
✅ پشتیبانی کامل از SQL با بیش از ۳۰۰ تابع توکار برای تحلیل‌های زمانی، پنجره‌ای و آماری
✅ دقت بالا با Exactly-Once Semantics حتی در صورت بروز خطا یا دریافت داده‌های نامرتب
✅ پشتیبانی از انواع پنجره‌ها (گروه‌بندی زمانی رخدادها): sliding، tumbling و session ⏱️
✅ اتصال به منابع متنوع مانند #Kafka 🧩، #Redis 🔴، #RabbitMQ 🐰 و CDC
✅ مقیاس‌پذیری برای پردازش میلیون‌ها رویداد در ثانیه ⚡️
✅ پشتیبانی از UDF با #Python 🐍، پروتکل Protobuf و مدیریت TTL در وضعیت‌ها
✅ امکان ساخت lookup tables برای داده‌های جریانی 🧷
📸 برای اینکه دقیقا متوجه شوید منظور از پردازش جریان با Arroyo آنهم فقط به کمک SQL چیست، می‌توانید به عکس‌های پایین این پست دقت کنید.
اکنون با پیوستن Arroyo به زیرساخت گسترده‌ی Cloudflare، کاربران می‌توانند از مزایای ترکیب پردازش آنی SQL (به کمک Arroyo)، ذخیره‌سازی ابری (R2)، صف‌های توزیع‌شده (Queues) و اجرای بدون سرور (Workers) در قالب یک پلتفرم یکپارچه و مقیاس‌پذیر بهره‌مند شوند.
🔓کتابخانه Arroyo همچنان متن‌باز و قابل میزبانی مستقل باقی خواهد ماند، و با حمایت Cloudflare از توسعه‌ی پایدار، افزایش کارایی و رشد جامعه‌ی کاربران خود بهره‌مند خواهد شد.
🚀 برای مهندسان داده، استارتاپ‌ها، مدیران محصول، تحلیل‌گران داده و تیم‌هایی که به‌دنبال جایگزینی سریع‌تر و ساده‌تر برای #ApacheFlink یا سایر ابزارهای پردازش جریان هستند، Arroyo اکنون نه‌تنها یک انتخاب هوشمندانه، بلکه یک بستر قدرتمند برای آینده است.
🦀 همچنین Arroyo نمونه‌ای از موج نوین پروژه‌های مبتنی بر زبان برنامه‌نویسی Rust است؛ زبانی که با امنیت بالا و مدیریت حافظه‌ی بسیار دقیق، در حال گشودن مرزهای تازه‌ای در دنیای زیرساخت‌های داده و پردازش بلادرنگ است.
www.arroyo.dev
Arroyo is joining Cloudflare
Arroyo has been acquired by Cloudflare to bring serverless SQL stream processing to the Cloudflare Developer Platfrorm, integrated with Queues, Workers, and R2. The Arroyo Engine will remain open-source and self-hostable.
کدام زبان: Rust یا Go؟ نگاهی دوباره از دل تجربه‌ی واقعی
چند وقت پیش مطلبی نوشتم با عنوان «آینده‌ی Rust در مهندسی داده» و یک مطلب دیگر در خصوص مهاجرت بخشی از کدهای #GO در دیسکورد به Rust. هنوز هم به آن حرف‌ها باور دارم:
اما بعد از چند ماه کار عملی با هر دو زبان، دیدگاهم واقع‌گرایانه‌تر شده است. Rust قدرت بالایی دارد، اما پیچیدگی توسعه و زمان بالای یادگیری، آن را برای همه‌ی پروژه‌ها مناسب نمی‌کند. Go در مقابل ساده، سریع، و برای توسعه‌ی روزمره بسیار کارآمد است.
🎯 یکی از تجربه‌های مهم برایم، پروژه‌ای بود که در آن یک تیم، یک سرویس واقعی را با سه زبان Rust، Go و Node.js پیاده‌سازی و در شرایط واقعی با ترافیک زنده تست کرد. تجربه‌ای که در زیر نتایج آنرا با هم مرور می‌کنیم. (لینک: https://freedium.cfd/https://medium.com/@kanishks772/we-didnt-benchmark-it-we-went-to-war-with-it-go-vs-rust-vs-node-at-1m-users-60565cd59b1f)
📌سرویسی که ساختند، شامل احراز هویت، پیام‌رسانی بلادرنگ، و آپلود فایل بود — چیزی شبیه به ستون فقرات یک اپلیکیشن پیام‌رسان. پیاده‌سازی اولیه با Node.js بود، اما دیگر جواب نمی‌داد: نشت حافظه، جهش‌های CPU، و زمان پاسخ‌هایی که باعث rage-quit کاربران می‌شد.
📚به‌جای فرضیه‌سازی، تیم دست‌به‌کار شد: همان سرویس را با Go و Rust هم نوشت و ترافیک را به‌طور مساوی بین هر سه تقسیم کرد. نتیجه چه شد؟
«Rust عملاً از نظر عملکرد، رقبا را پشت سر گذاشت.» اما آنچه این تیم یاد گرفت، چیزی بود که اغلب در بنچمارک‌ها دیده نمی‌شود:
عملکرد بالا، بدون بهره‌وری، کافی نیست.
در نهایت، این تیم از هر سه زبان استفاده کرد:
🔹 Node.js برای ابزارهای مدیریتی و پروتوتایپ‌های سریع
🔹 #Go برای سرویس‌های اصلی و عمومی
🔹 #Rust برای بخش‌هایی که واقعاً performance-critical بودند
درس‌هایی از میدان نبرد
✅ واقعیت از بنچمارک قوی‌تر است. کدی که در تولید اجرا شود، تفاوت‌ها را نشان می‌دهد، نه کدهایی که فقط در محیط‌های تست اجرا شده‌اند.
✅ تجربه‌ی تیم از زبان مهم‌تر است. زبانی که تیم در آن مهارت دارد، اغلب از زبان بهتری که تیم با آن غریبه است، نتیجه‌ی بهتری می‌دهد.
✅ انتخاب تکنولوژی، مسابقه‌ی محبوبیت نیست. برنده، زبانی است که بهترین توازن بین بهره‌وری، عملکرد، و قابل نگهداری بودن را برای پروژه‌ی خاص شما ایجاد کند.
✅ چندزبانی بودن (polyglot) مزیت است، نه نقطه‌ضعف. گاهی بهترین راه این است که یک زبان را همه‌جا استفاده نکنیم. هر ابزار برای کاری ساخته شده.
💡 نتیجه‌گیری شخصی من
زبان Rust هنوز آینده‌ی ابزارهای مهندسی داده است — مخصوصاً در سطح زیرساخت. اما در بسیاری از پروژه‌های کاربردی، از سرویس‌های داخلی گرفته تا microserviceهای API، Go انتخابی‌ست منطقی‌تر و واقع‌گرایانه‌تر.
ما همه مثل Discord نیستیم. منابع، مقیاس و اولویت‌های تیم‌ها متفاوت‌اند.
اما مهم‌تر از انتخاب بین Rust یا Go، این است که انتخاب‌مان با چشمان باز باشد — از دل تجربه، نه فقط از روی بنچمارک‌ها یا توییت‌های ترند شده.
چند وقت پیش مطلبی نوشتم با عنوان «آینده‌ی Rust در مهندسی داده» و یک مطلب دیگر در خصوص مهاجرت بخشی از کدهای #GO در دیسکورد به Rust. هنوز هم به آن حرف‌ها باور دارم:
بخش زیادی از ابزارهای آینده‌ی این حوزه یا با #Rust بازنویسی می‌شوند یا به شکل native با آن توسعه می‌یابند — دلیلش هم مشخص است: سرعت بالا، کنترل دقیق حافظه، و ویژگی‌هایی مثل «zero-cost abstractions»
اما بعد از چند ماه کار عملی با هر دو زبان، دیدگاهم واقع‌گرایانه‌تر شده است. Rust قدرت بالایی دارد، اما پیچیدگی توسعه و زمان بالای یادگیری، آن را برای همه‌ی پروژه‌ها مناسب نمی‌کند. Go در مقابل ساده، سریع، و برای توسعه‌ی روزمره بسیار کارآمد است.
🎯 یکی از تجربه‌های مهم برایم، پروژه‌ای بود که در آن یک تیم، یک سرویس واقعی را با سه زبان Rust، Go و Node.js پیاده‌سازی و در شرایط واقعی با ترافیک زنده تست کرد. تجربه‌ای که در زیر نتایج آنرا با هم مرور می‌کنیم. (لینک: https://freedium.cfd/https://medium.com/@kanishks772/we-didnt-benchmark-it-we-went-to-war-with-it-go-vs-rust-vs-node-at-1m-users-60565cd59b1f)
📌سرویسی که ساختند، شامل احراز هویت، پیام‌رسانی بلادرنگ، و آپلود فایل بود — چیزی شبیه به ستون فقرات یک اپلیکیشن پیام‌رسان. پیاده‌سازی اولیه با Node.js بود، اما دیگر جواب نمی‌داد: نشت حافظه، جهش‌های CPU، و زمان پاسخ‌هایی که باعث rage-quit کاربران می‌شد.
📚به‌جای فرضیه‌سازی، تیم دست‌به‌کار شد: همان سرویس را با Go و Rust هم نوشت و ترافیک را به‌طور مساوی بین هر سه تقسیم کرد. نتیجه چه شد؟
«Rust عملاً از نظر عملکرد، رقبا را پشت سر گذاشت.» اما آنچه این تیم یاد گرفت، چیزی بود که اغلب در بنچمارک‌ها دیده نمی‌شود:
عملکرد بالا، بدون بهره‌وری، کافی نیست.
⚠️توسعه با Rust 40٪ زمان بیشتری می‌برد. اشکال‌زدایی درگیر borrow checker می‌شد و اضافه‌کردن یک فیچر ساده، به جنگ با سیستم Typing منتهی می‌گردید.
✅در مقابل، Go سرعت توسعه‌ی بالایی داشت، کتابخانه استاندارد کافی و کاربردی، و راه‌اندازی ساده. هرچند کمی از Rust کندتر بود، اما برای تیم، توسعه با Go سه برابر سریع‌تر از Rust و دو برابر سریع‌تر از Node بود.
در نهایت، این تیم از هر سه زبان استفاده کرد:
🔹 Node.js برای ابزارهای مدیریتی و پروتوتایپ‌های سریع
🔹 #Go برای سرویس‌های اصلی و عمومی
🔹 #Rust برای بخش‌هایی که واقعاً performance-critical بودند
درس‌هایی از میدان نبرد
✅ واقعیت از بنچمارک قوی‌تر است. کدی که در تولید اجرا شود، تفاوت‌ها را نشان می‌دهد، نه کدهایی که فقط در محیط‌های تست اجرا شده‌اند.
✅ تجربه‌ی تیم از زبان مهم‌تر است. زبانی که تیم در آن مهارت دارد، اغلب از زبان بهتری که تیم با آن غریبه است، نتیجه‌ی بهتری می‌دهد.
✅ انتخاب تکنولوژی، مسابقه‌ی محبوبیت نیست. برنده، زبانی است که بهترین توازن بین بهره‌وری، عملکرد، و قابل نگهداری بودن را برای پروژه‌ی خاص شما ایجاد کند.
✅ چندزبانی بودن (polyglot) مزیت است، نه نقطه‌ضعف. گاهی بهترین راه این است که یک زبان را همه‌جا استفاده نکنیم. هر ابزار برای کاری ساخته شده.
💡 نتیجه‌گیری شخصی من
زبان Rust هنوز آینده‌ی ابزارهای مهندسی داده است — مخصوصاً در سطح زیرساخت. اما در بسیاری از پروژه‌های کاربردی، از سرویس‌های داخلی گرفته تا microserviceهای API، Go انتخابی‌ست منطقی‌تر و واقع‌گرایانه‌تر.
ما همه مثل Discord نیستیم. منابع، مقیاس و اولویت‌های تیم‌ها متفاوت‌اند.
اما مهم‌تر از انتخاب بین Rust یا Go، این است که انتخاب‌مان با چشمان باز باشد — از دل تجربه، نه فقط از روی بنچمارک‌ها یا توییت‌های ترند شده.
👍6