دوال Serverless بلغة JavaScript: AWS Lambda وما يماثلها للمطور

Serverless بلغة JavaScript: كيف تتوقف عن التفكير في الخوادم وتبدأ في كتابة الكود

تخيل: لقد كتبت خدمة رائعة، وأطلقتها، وبعد شهر لم يعد أحد يحتاجها. أنت تدفع ثمن خادم لا يُستخدم. أو العكس - يحدث لك تأثير "هابر" (زيادة مفاجئة في الزوار)، فينهار الخادم، وأنت في الساعة الثالثة صباحًا تُصلح nginx. هل هذا مألوف؟ هناك طريقة للتخلص من هذا الصداع - دوال serverless بلغة JavaScript.

Serverless (أو الحوسبة بلا خوادم) ليست سحرًا، بل نموذج حيث تكتب الكود فقط، والمزود (AWS، Google، Yandex) هو من يقرر متى وأين وكم من الموارد سيخصصها. أنت تدفع فقط مقابل وقت التنفيذ وعدد الطلبات. لا مزيد من "الخوادم العاملة دائمًا". بالنسبة لمطور JavaScript، هذا مريح بشكل خاص: Node.js هي البيئة الأصلية لـ AWS Lambda و Google Cloud Functions و Yandex Cloud Functions.

في هذه المقالة، لن نكتفي بشرح النظرية. سنكتب دوالًا حقيقية، ونقارن بين المزودين، ونقدم قائمة مرجعية لتجنب الوقوع في الأخطاء. هيا بنا!

ما هي دالة serverless وما فائدتها لمطور JS؟

دالة serverless هي قطعة من الكود (عادةً دالة واحدة) يتم تنفيذها استجابةً لحدث. يمكن أن يكون الحدث طلب HTTP، أو رفع ملف إلى S3، أو كتابة في قاعدة بيانات، أو حتى إشارة من مؤقت (cron).

لماذا هذا مناسب لـ JavaScript:

\n
• بداية سريعة - لا حاجة لإعداد خادم، يكفي رفع الكود.
\n
• توسع تلقائي - الدالة تتضاعف تلقائيًا تحت الضغط.
\n
• توفير - طالما لا أحد يستدعي الدالة، لا تدفع شيئًا.
\n
• النظام البيئي - Node.js مدعوم من جميع المزودين الكبار.
\n

سيناريوهات نموذجية: معالجة webhooks، إنشاء صور مصغرة، إرسال رسائل بريدية، التحقق من صحة النماذج، تحليل البيانات، إنشاء خدمات مصغرة. كل ما يمكن تشغيله عند الطلب.

AWS Lambda - ملك serverless في JavaScript

خدمة Amazon Web Services Lambda هي الأكثر شهرة. ظهرت أولاً وما زالت تضع المعايير. لنكتب دالة بسيطة تستقبل JSON وتعيد ردًا.

كود لـ AWS Lambda على Node.js 20:

export const handler = async (event) => {\n  try {\n    const { name } = JSON.parse(event.body || '{}');\n    const message = `مرحبًا، ${name || 'ضيف'}! لقد استدعيت دالة serverless بنجاح.`;\n    \n    return {\n      statusCode: 200,\n      headers: {\n        'Content-Type': 'application/json',\n        'Access-Control-Allow-Origin': '*',\n      },\n      body: JSON.stringify({ message, timestamp: Date.now() }),\n    };\n  } catch (error) {\n    return {\n      statusCode: 400,\n      body: JSON.stringify({ error: 'JSON غير صحيح' }),\n    };\n  }\n};

لاحظ: الدالة تُسمى handler. هذا هو الاسم القياسي لنقطة الدخول. المعامل event يحتوي على كل ما ورد من API Gateway - الترويسات، الجسم، معاملات الطلب. أنت تُعيد كائنًا مع statusCode و body.

كيف يعمل هذا: تنشئ دالة في وحدة تحكم AWS، ترفع الكود (أو تستخدم SAM/Serverless Framework)، وتُعدّل مشغلًا - مثل نقطة نهاية HTTP عبر API Gateway. هذا كل شيء. أصبح العالم أبسط.

البدء البارد وكيفية التعامل معه

العيب الرئيسي في Lambda هو البدء البارد. إذا لم يتم استدعاء الدالة لفترة طويلة، عند أول طلب، يتم تحميل البيئة من جديد. قد يستغرق ذلك 200-500 مللي ثانية. بالنسبة لواجهات API عالية التحميل، هذا أمر بالغ الأهمية. الحلول:

\n
• حافظ على الدالة "دافئة" باستخدام CloudWatch Events (إرسال ping كل 5 دقائق).
\n
• قلل حجم الحزمة - لا تسحب حزم npm غير الضرورية.
\n
• استخدم Provisioned Concurrency (لكنه أغلى).
\n

بالنسبة لمعظم الخدمات المصغرة، البدء البارد ليس مشكلة. ولكن إذا كنت تكتب بوت محادثة حيث السرعة مهمة، ضع ذلك في الاعتبار.

Google Cloud Functions - البساطة والتكامل مع Firebase

Go