Promises مقابل async/await: متى تختار كل أداة ولماذا قد تكون مخطئاً بشأنهما

في أحد الأيام، بينما كنت أراجع كود فريق جديد في شركة ناشئة تعمل على منصة تداول مالي، وجدت سطراً غريباً: await new Promise(resolve => setTimeout(resolve, 1000)). لم يكن الخطأ في استخدام await بحد ذاته، بل في المكان الذي وُضع فيه - داخل حلقة تكرارية تعالج آلاف الطلبات في الثانية. النتيجة؟ السيرفر تجمد تماماً بعد دقيقتين، والـ Event Loop علق في انتظار كل Promise على حدة بدلاً من معالجتها بشكل متزامن. هذه اللحظة كانت بداية فهمي العميق أن الفرق بين Promises وasync/await ليس مجرد مسألة أسلوب، بل قرار هندسي يؤثر على أداء النظام واستقراره.

الكثير من المطورين يعاملون async/await كحل نهائي لكل مشاكل الـ asynchronous في JavaScript، معتقدين أنه مجرد واجهة أجمل للـ Promises. لكن الحقيقة أن كل أداة لها استخداماتها الدقيقة، وفهم الفرق العميق بينهما يمكن أن يفرق بين نظام سريع وسلس وآخر بطيء ومعرض للانهيار تحت الضغط. في هذا المقال، سنفكك كيف يعمل كل منهما على مستوى الـ Engine، ومتى يكون استخدام أحدهما خطأً فادحاً، وكيف تتجنب الفخاخ الشائعة التي يقع فيها حتى المطورون ذوو الخبرة.

الأسطورة الأولى: async/await مجرد واجهة تجميلية للـ Promises

عندما ظهرت async/await في ES2017، ساد اعتقاد خاطئ بأنها مجرد صياغة مختلفة للـ Promises، مثل اختلاف الـ for loop عن الـ forEach. لكن الواقع أكثر تعقيداً بكثير. في حين أن كل دالة async تُرجع Promise، فإن الطريقة التي يتعامل بها الـ JavaScript Engine مع الكود المكتوب بـ await تختلف جذرياً عن التعامل مع سلسلة من then(). لنأخذ مثالاً بسيطاً:

// باستخدام Promises
function fetchData() {
 return fetch('/api/data')
 .then(resp> response.json())
 .then(data => process(data))
 .catch(error => console.error(error));
}

// باستخدام async/await
async function fetchDataAsync() {
 try {
 const response = await fetch('/api/data');
 const data = await response.json();
 return process(data);
 } catch (error) {
 console.error(error);
 }
}

للوهلة الأولى، يبدو الكود الثاني أكثر نظافة وسهولة في القراءة. لكن خلف الكواليس، يحدث شيء مختلف تماماً. عندما يستخدم الـ Engine كلمة await، فإنه يقوم بتحويل الكود إلى ما يُعرف بـ state machine. هذه الآلة تحافظ على سياق التنفيذ الحالي وتستأنفه عندما يكتمل الـ Promise، مما يعني أن كل await هو نقطة توقف فعلية في التنفيذ، وليس مجرد استدعاء لـ then() آخر في السلسلة.

المشكلة هنا أن الكثير من المطورين لا يدركون أن هذه الـ state machine تأتي بتكلفة. في سيناريوهات الـ tight loops أو العمليات الحسابية المكثفة، يمكن أن يؤدي استخدام await بشكل مفرط إلى زيادة في استهلاك الذاكرة، خاصة إذا كانت الـ Promises تُنشأ داخل حلقات تكرارية. في أحد المشاريع التي عملت عليها، أدى تحويل حلقة معالجة بيانات من Promises إلى async/await إلى زيادة استهلاك الذاكرة بنسبة 40% بسبب احتفاظ الـ state machine بسياقات التنفيذ لكل تكرار في الحلقة.

كيف يعمل الـ Event Loop مع كل منهما: الفارق الحاسم

لفهم الفرق الحقيقي بين Promises وasync/await، يجب أن نغوص في أعماق الـ Event Loop وكيفية تعاملها مع كل منهما. عندما تستخدم سلسلة من then()، فإن كل then() يُضاف إلى الـ microtask queue ويتم تنفيذه بمجرد اكتمال الـ Promise السابق. هذا يعني أن التنفيذ يتدفق بشكل مستمر دون توقف، حتى لو كان الكود يبدو متسلسلاً:

console.log('Start');

fetch('/api/data')
 .then(resp> {
 console.log('Response received');
 return response.json();
 })
 .then(data => {
 console.log('Data processed');
 });

console.log('End');
// Output: Start → End → Response received → Data processed

في هذا المثال، يتم تنفيذ console.log('End') قبل معالجة الـ Promise لأن الـ then() يُضاف إلى الـ microtask queue ولا يعطل تدفق التنفيذ الرئيسي. لكن مع await، يحدث شيء مختلف تماماً:

async function demo() {
 console.log('Start');
 const resp await fetch('/api/data');
 console.log('Response received');
 const data = await response.json();
 console.log('Data processed');
 console.log('End');
}

demo();
// Output: Start → Response received → Data processed → End

هنا، console.log('End') لا يُنفذ حتى تكتمل جميع الـ await داخل الدالة. هذا لأن await يُوقف تنفيذ الدالة الحالية تماماً وينتظر اكتمال الـ Promise، ثم يستأنف التنفيذ من حيث توقف. هذا السلوك يجعل الكود يبدو متزامناً، لكنه في الواقع يحتفظ بسياق التنفيذ في الذاكرة، مما قد يؤدي إلى مشاكل في السيناريوهات التالية:

• •عندما يكون لديك عدة عمليات I/O متوازية تحتاج إلى البدء في نفس الوقت، مثل جلب بيانات من عدة واجهات برمجية في وقت واحد.
• •في حلقات التكرار التي تعالج كميات كبيرة من البيانات، حيث كل await داخل الحلقة يضيف تأخيراً تراكمياً.
• •في التطبيقات التي تحتاج إلى استجابة فورية، مثل الألعاب أو تطبيقات الوقت الحقيقي، حيث أي توقف في التنفيذ يمكن أن يسبب تأخيراً ملحوظاً.
• •عند التعامل مع الـ long-running tasks التي قد تستغرق وقتاً طويلاً، حيث احتفاظ الـ state machine بسياق التنفيذ يمكن أن يؤدي إلى زيادة في استهلاك الذاكرة.

متى يكون استخدام await خطأً فادحاً؟

هناك عدة سيناريوهات شائعة حيث يعتبر استخدام await خطأً هندسياً يمكن أن يؤدي إلى مشاكل في الأداء أو حتى فشل النظام. أحد أكثر الأخطاء شيوعاً هو استخدام await داخل حلقات التكرار لمعالجة بيانات متوازية. لنأخذ مثالاً واقعياً من مشروع حقيقي:

// خطأ شائع: استخدام await داخل حلقة تكرارية
async function processUsersSequentially(userIds) {
 const results = [];
 for (const id of userIds) {
 const user = await fetchUser(id); // كل طلب ينتظر اكتمال السابق
 results.push(user);
 }
 return results;
}

// الحل الصحيح: استخدام Promise.all
async function processUsersInParallel(userIds) {
 const promises = userIds.map(id => fetchUser(id));
 return Promise.all(promises);
}

في المثال الأول، إذا كان لدينا 1000 مستخدم، فإن كل طلب سيستغرق مثلاً 200 مللي ثانية، مما يعني أن الوقت الإجمالي سيكون حوالي 200 ثانية. أما في المثال الثاني، فسيتم إرسال جميع الطلبات في نفس الوقت، وسيستغرق الأمر حوالي 200 مللي ثانية فقط، بغض النظر عن عدد المستخدمين. هذا الفرق يمكن أن يكون حاسماً في تطبيقات الإنتاج، خاصة تلك التي تعالج كميات كبيرة من البيانات.

مشكلة أخرى شائعة هي استخدام await مع العمليات التي لا تحتاج إلى انتظار، مثل إرسال رسائل إلى الـ queue أو تسجيل البيانات. في أحد المشاريع التي عملت عليها، كان هناك سطر مثل هذا:

await logToDatabase(userAction); // خطأ: لا حاجة للانتظار هنا

هذا السطر كان يسبب بطء ملحوظ في استجابة الواجهة الأمامية لأن الـ Event Loop كان ينتظر اكتمال عملية تسجيل البيانات قبل المتابعة، على الرغم من أن هذه العملية ليست ضرورية لتجربة المستخدم. الحل الصحيح كان ببساطة إزالة await، أو استخدام Promise.all إذا كان هناك عدة عمليات تسجيل تحتاج إلى الانتظار لها:

// الحل الصحيح: لا تنتظر العمليات التي لا تحتاج إلى انتظار
logToDatabase(userAction); // أسرع بكثير

// أو إذا كان هناك عدة عمليات
Promise.all([
 logToDatabase(action1),
 logToDatabase(action2)
]); // انتظر فقط إذا كان ضرورياً

حالة خاصة: الـ CPU-bound tasks

أحد أكثر المفاهيم الخاطئة شيوعاً هو الاعتقاد أن async/await يمكن أن يجعل العمليات الحسابية الثقيلة أسرع. الحقيقة أن JavaScript لا تزال لغة أحادية الخيط، وأي عملية CPU-bound ستعطل الـ Event Loop بغض النظر عن استخدام Promises أو async/await. في أحد المشاريع، حاول فريق تطوير تحسين أداء خوارزمية معالجة صور باستخدام async/await، معتقدين أن ذلك سيسمح للواجهة الأمامية بالاستجابة أثناء المعالجة:

// خطأ: هذا لن يجعل المعالجة أسرع
async function processImage(imageData) {
 const result = await heavyComputation(imageData); // لا يزال يعطل الـ Event Loop
 return result;
}

الحل الصحيح في مثل هذه الحالات هو استخدام الـ Web Workers لفصل المعالجة الثقيلة عن الخيط الرئيسي، أو تقسيم المهمة إلى أجزاء أصغر واستخدام setImmediate أو setTimeout للسماح للـ Event Loop بمعالجة الأحداث الأخرى بين كل جزء:

// حل أفضل: تقسيم المهمة إلى أجزاء أصغر
function processImageInChunks(imageData, callback) {
 const chunks = splitIntoChunks(imageData);
 let index = 0;

 function processNextChunk() {
 if (index >= chunks.length) {
 return callback(null, combineResults(chunks));
 }
 heavyComputation(chunks[index], (err, result) => {
 if (err) return callback(err);
 chunks[index] = result;
 index++;
 setImmediate(processNextChunk); // يسمح للـ Event Loop بمعالجة أحداث أخرى
 });
 }

 processNextChunk();
}

متى يجب استخدام Promises بشكل مباشر؟

على الرغم من أن async/await أصبح الخيار المفضل للكثيرين، إلا أن هناك حالات يكون فيها استخدام Promises بشكل مباشر هو الخيار الأفضل، بل وأحياناً الوحيد. أحد هذه الحالات هو عند الحاجة إلى التحكم الدقيق في تدفق التنفيذ، خاصة في السيناريوهات المتقدمة مثل:

• •تنفيذ عدة عمليات بشكل متوازٍ مع تحديد الحد الأقصى لعدد العمليات المتزامنة (مثل الـ concurrency limit في مكتبات مثل p-limit).
• •التعامل مع الـ Promise chains المعقدة التي تتطلب منطق شرطية متقدم أو معالجة الأخطاء التفصيلية.
• •إنشاء مكتبات أو أدوات تتطلب واجهة مرنة يمكن استخدامها مع كل من الـ callback-style وPromise-style.
• •السيناريوهات التي تتطلب إلغاء الـ Promises (مثل استخدام AbortController مع fetch).
• •عند الحاجة إلى تنفيذ عمليات بشكل متسلسل مع إمكانية تخطي بعضها بناءً على شروط معينة.

لنأخذ مثالاً عملياً على الحاجة إلى التحكم في عدد العمليات المتزامنة. في أحد المشاريع التي عملت عليها، كنا بحاجة إلى تحميل آلاف الصور من سيرفر خارجي، لكننا لم نكن نريد إرسال أكثر من 10 طلبات في نفس الوقت لتجنب تحميل السيرفر أو تجاوز حدود الـ rate limiting:

function limitConcurrency(promises, limit) {
 const results = [];
 let currentIndex = 0;
 let activePromises = 0;

 return new Promise((resolve, reject) => {
 function runNext() {
 if (currentIndex >= promises.length && activePromises === 0) {
 return resolve(results);
 }

 while (activePromises < limit && currentIndex < promises.length) {
 const index = currentIndex++;
 const promise = promises[index];
 activePromises++;

 promise.then(result => {
 results[index] = result;
 activePromises--;
 runNext();
 }).catch(error => {
 reject(error);
 });
 }
 }

 runNext();
 });
}

// الاستخدام
const imageUrls = [...]; // قائمة طويلة من عناوين الصور
const promises = imageUrls.map(url => fetchImage(url));
limitConcurrency(promises, 10).then(results => {
 console.log('تم تحميل جميع الصور:', results);
});

هذا النوع من التحكم الدقيق في التنفيذ يكاد يكون مستحيلاً باستخدام async/await وحده دون اللجوء إلى مكتبات خارجية. كما أن استخدام Promises بشكل مباشر يمنحك مرونة أكبر في التعامل مع الأخطاء وإدارة تدفق البيانات، خاصة في السيناريوهات المعقدة مثل الـ retry logic أو الـ fallback mechanisms.

حالة خاصة: الـ Promise.race والـ Promise.any

هناك بعض السيناريوهات التي تتطلب استخدام دوال مدمجة في الـ Promise API لا يمكن محاكاتها بسهولة باستخدام async/await. أحد هذه السيناريوهات هو عندما تحتاج إلى تنفيذ عدة عمليات متوازية واختيار أول نتيجة ناجحة، مثل:

// محاولة الاتصال بأحد عدة سيرفرات واختيار الأسرع
async function fetchFromFastestServer(urls) {
 const promises = urls.map(url => fetch(url).then(res => res.json()));
 return Promise.any(promises); // يرجع أول promise ناجح
}

// أو إذا كنت تريد أول نتيجة بغض النظر عن النجاح أو الفشل
async function fetchFirstResponse(urls) {
 const promises = urls.map(url => fetch(url));
 return Promise.race(promises); // يرجع أول promise يكتمل (سواء نجح أو فشل)
}

هذه الاستخدامات تجعل من الصعب التخلي تماماً عن الـ Promises، حتى في الكود الذي يستخدم async/await بشكل أساسي. في الواقع، العديد من المكتبات الحديثة مثل axios وnode-fetch تستخدم مزيجاً من الاثنين لتحقيق أفضل أداء ومرونة.

الـ Memory Leaks والـ Garbage Collection: الجانب المظلم لasync/await

أحد الجوانب التي غالباً ما يتم تجاهلها عند الحديث عن Promises وasync/await هو تأثيرهما على إدارة الذاكرة. في حين أن الـ Promises التقليدية تُحرر مواردها بمجرد اكتمالها (سواء بالنجاح أو الفشل)، فإن استخدام await يمكن أن يؤدي إلى احتفاظ الـ JavaScript Engine بسياقات التنفيذ لفترة أطول من اللازم، مما قد يسبب تسريبات ذاكرة في بعض الحالات.

المشكلة تكمن في كيفية تعامل الـ Engine مع الـ state machine التي تُنشأ لكل دالة async. هذه الآلة تحتفظ بمرجع لكل متغير محلي وكل سياق تنفيذ حتى تكتمل الدالة بالكامل. في السيناريوهات التي تستخدم فيها حلقات تكرارية طويلة أو الـ recursive functions مع await، يمكن أن يؤدي هذا إلى تراكم كبير في الذاكرة. لنأخذ مثالاً بسيطاً:

async function processLargeArray(array) {
 const results = [];
 for (const item of array) {
 const result = await processItem(item); // كل await يحتفظ بسياق التنفيذ
 results.push(result);
 }
 return results;
}

في هذا المثال، إذا كان المصفوفة تحتوي على 10,000 عنصر، فسيتم الاحتفاظ بسياق التنفيذ لكل تكرار في الحلقة حتى تكتمل الدالة بالكامل. هذا يمكن أن يؤدي إلى زيادة كبيرة في استخدام الذاكرة، خاصة إذا كانت عملية processItem() تستغرق وقتاً طويلاً. الحل في مثل هذه الحالات هو إما استخدام Promise.all كما ذكرنا سابقاً، أو تقسيم المهمة إلى أجزاء أصغر تعالج بشكل متسلسل دون استخدام await داخل الحلقة:

async function processLargeArrayEfficiently(array) {
 const results = [];
 let index = 0;

 async function processNext() {
 if (index >= array.length) return results;
 const result = await processItem(array[index++]);
 results.push(result);
 return processNext(); // لا يحتفظ بسياق التنفيذ لكل تكرار
 }

 return processNext();
}

هذا الأسلوب يستخدم الـ tail recursion (أو شبهه) مما يسمح للـ Engine بإعادة استخدام نفس سياق التنفيذ لكل تكرار، مما يقلل بشكل كبير من استخدام الذاكرة. في أحد المشاريع التي عملت عليها، أدى تحويل حلقة معالجة البيانات من الأسلوب الأول إلى الأسلوب الثاني إلى تقليل استخدام الذاكرة بنسبة 60%، مما سمح لنا بمعالجة مجموعات بيانات أكبر بكثير دون الحاجة إلى زيادة موارد السيرفر.

الـ Event Listeners والـ async functions

مشكلة أخرى تتعلق بإدارة الذاكرة تظهر عند استخدام الدوال غير المتزامنة مع الـ event listeners. إذا لم يتم التعامل معها بعناية، يمكن أن تؤدي إلى تسريبات ذاكرة خطيرة. لنأخذ مثالاً شائعاً:

// خطأ: يمكن أن يؤدي إلى تسريب ذاكرة
button.addEventListener('click', async () => {
 const data = await fetchData();
 updateUI(data);
});

المشكلة هنا أن كل مرة يُضغط فيها على الزر، يتم إنشاء دالة async جديدة، وتُضاف إلى قائمة الـ event listeners. إذا لم يتم إزالة الـ listener بشكل صحيح، فسيتم الاحتفاظ بمراجع لكل دالة من هذه الدوال، مما يؤدي إلى تراكم الذاكرة. الحل الصحيح هو إما إزالة الـ listener عند عدم الحاجة إليه، أو استخدام نمط مختلف تماماً:

// الحل الأفضل: استخدم دالة غير متزامنة خارجية
async function handleClick() {
 const data = await fetchData();
 updateUI(data);
}

button.addEventListener('click', handleClick);
// ثم عند الحاجة لإزالة الـ listener
button.removeEventListener('click', handleClick);

هذا الأسلوب يضمن عدم إنشاء دالة جديدة في كل مرة، مما يمنع تسريب الذاكرة. كما أنه يجعل الكود أكثر قابلية لإعادة الاستخدام وأسهل في الاختبار.

خلاصة المهندس: متى تختار كل أداة ولماذا

بعد سنوات من العمل مع كلا الأداتين في مشاريع مختلفة، من التطبيقات الصغيرة إلى الأنظمة الموزعة الكبيرة، توصلت إلى قاعدة بسيطة لكنها فعالة: استخدم async/await عندما تريد كتابة كود نظيف وسهل القراءة لمعالجة العمليات المتسلسلة، خاصة إذا كانت هذه العمليات تعتمد على بعضها البعض. أما استخدم Promises بشكل مباشر عندما تحتاج إلى تحكم دقيق في تدفق التنفيذ، أو عندما تعمل مع عمليات متوازية تتطلب إدارة معقدة للـ concurrency أو معالجة الأخطاء التفصيلية.

لكن القاعدة الأهم هي: لا تعامل أي أداة على أنها حل سحري. فهم كيف يعمل كل منهما خلف الكواليس، ومعرفة متى يكون استخدام أحدهما خطأً، هو ما يميز المطور الجيد عن المطور الممتاز. في المرة القادمة التي تكتب فيها دالة غير متزامنة، اسأل نفسك: هل أحتاج حقاً إلى انتظار هذا الـ Promise؟ هل هذا الانتظار سيؤثر على أداء النظام؟ وهل هناك طريقة أفضل لتحقيق نفس النتيجة؟ الإجابة على هذه الأسئلة ستقودك دائماً إلى القرار الصحيح.

وأخيراً، تذكر أن JavaScript تتطور باستمرار، والأدوات الجديدة تظهر طوال الوقت. لكن الفهم العميق للأساسيات - مثل كيفية عمل الـ Event Loop، وكيفية إدارة الذاكرة، وكيفية تعامل الـ Engine مع الكود غير المتزامن - هو ما سيمكنك من اتخاذ القرارات الصحيحة بغض النظر عن الأداة التي تستخدمها. في عالم البرمجة، المعرفة العميقة دائماً ما تفوز على الحلول السريعة.