أصبحت الواجهة الأمامية تُحمَّل من مواقع الحافة خلال أجزاء من الألف من الثانية. لكن تأكيد الحضور ليس ملفًا ثابتًا: يجب التحقّق منه، وتخزينه، وعدّه. على الخادم القديم كان ذلك مسارًا (route) في تطبيق Node.js، يعمل طوال اليوم من أجل الدقائق القليلة في الأسبوع التي يؤكّد فيها أحدهم حضوره. أما الآن فيصبح ثلاث قطع مُدارة لا تكلّف شيئًا وهي خاملة، وتتوسّع حين تنتشر فعالية ما.
\nمساران يكفيان للإطلاق:
\n| المسار | \nما يفعله | \n
|---|---|
POST /events/{eventId}/rsvps | \nيخزّن تأكيد حضور واحدًا، ويرفض التكرار | \n
GET /events/{eventId}/rsvps | \nيعيد عدد تأكيدات الحضور للفعالية | \n
يمرّر الـ HTTP API في API Gateway إلى Lambda حدث JSON (بصيغة الحمولة 2.0) يحتوي على معاملات المسار (path parameters) والطريقة (method) والمحتوى كنص. وتعيد الدالة رمز حالة وترويسات ومحتوى نصيًا:
\nimport { DynamoDBClient } from \"@aws-sdk/client-dynamodb\";\nimport { DynamoDBDocumentClient, PutCommand, QueryCommand } from \"@aws-sdk/lib-dynamodb\";\n\n// Created once per execution environment and reused across invocations.\n// removeUndefinedValues: an RSVP without a \"name\" is stored without that attribute.\nconst db = DynamoDBDocumentClient.from(new DynamoDBClient({}), {\n marshallOptions: { removeUndefinedValues: true },\n});\nconst TABLE = process.env.TABLE_NAME;\n\nconst reply = (statusCode, data) => ({\n statusCode,\n headers: { \"content-type\": \"application/json\" },\n body: JSON.stringify(data),\n});\n\nexport const handler = async (event) => {\n const eventId = event.pathParameters?.eventId;\n\n if (event.requestContext.http.method === \"GET\") {\n const res = await db.send(new QueryCommand({\n TableName: TABLE,\n KeyConditionExpression: \"eventId = :e\",\n ExpressionAttributeValues: { \":e\": eventId },\n Select: \"COUNT\",\n }));\n return reply(200, { eventId, count: res.Count });\n }\n\n const { email, name } = JSON.parse(event.body ?? \"{}\");\n if (typeof email !== \"string\" || !email.includes(\"@\")) {\n return reply(400, { error: \"A valid email is required\" });\n }\n\n try {\n await db.send(new PutCommand({\n TableName: TABLE,\n Item: { eventId, email: email.toLowerCase(), name, createdAt: new Date().toISOString() },\n ConditionExpression: \"attribute_not_exists(email)\",\n }));\n } catch (err) {\n if (err.name === \"ConditionalCheckFailedException\") {\n return reply(409, { error: \"You have already RSVPed to this event\" });\n }\n throw err;\n }\n return reply(201, { eventId, email });\n};لاحظ ما ليس موجودًا: لا بيانات اعتماد، ولا ARN للجدول، ولا مجمّع اتصالات (connection pool). تعثر الـ SDK على بيانات اعتماد الـ execution role، ويأتي اسم الجدول من متغيّر بيئة كي يعمل الكود نفسه على جداول التطوير والإنتاج. تتضمّن بيئة تشغيل Node.js الإصدار v3 من AWS SDK for JavaScript، لكن احزم مع الكود الخاص بك الإصدار الذي اختبرته، كي لا يغيّره تحديث لبيئة التشغيل من تحت قدميك.
\nوهناك حدّ واحد يجب ذكره بصراحة: يقرأ Query الواحد 1 MB كحد أقصى، لذا فإن فعالية بعدد هائل من تأكيدات الحضور ستحتاج في العدّ إلى تقسيم إلى صفحات (pagination)، أو إلى عنصر عدّاد منفصل يُحدَّث مع كل كتابة. أما لفعاليات Lantern، فاستدعاء واحد أكثر من كافٍ.
\n\nيحصل الـ execution role الخاص بالدالة على ما يستدعيه الكود بالضبط، على جدول واحد بالضبط، إضافة إلى السياسة المُدارة من AWS AWSLambdaBasicExecutionRole كي يستطيع كتابة السجلات:
{\n \"Version\": \"2012-10-17\",\n \"Statement\": [\n {\n \"Sid\": \"RsvpTable\",\n \"Effect\": \"Allow\",\n \"Action\": [\"dynamodb:PutItem\", \"dynamodb:Query\"],\n \"Resource\": \"arn:aws:dynamodb:eu-west-1:111122223333:table/lantern-rsvps\"\n }\n ]\n}والاتجاه الآخر هو السياسة القائمة على المورد الخاصة بالدالة: يحق لـ API Gateway استدعاؤها. يضيف الـ console هذه السياسة حين تربط مسارًا؛ ومن الـ CLI تبدو هكذا، مقيّدة بـ API واحد عبر الـ ARN الخاص به:
\naws lambda add-permission --function-name lantern-rsvp \\\n --statement-id allow-lantern-http-api \\\n --action lambda:InvokeFunction \\\n --principal apigateway.amazonaws.com \\\n --source-arn \"arn:aws:execute-api:eu-west-1:111122223333:a1b2c3d4e5/*\"في console الـ API Gateway، أنشئ HTTP API، وأضف المسارين مع تكامل Lambda (Lambda integration) إلى lantern-rsvp، واستخدم المرحلة $default التي تُنشر تلقائيًا. الـ HTTP APIs هي النوع الأرخص والأبسط. واختر REST API بدلًا منها حين تحتاج إلى API keys مع خطط الاستخدام، أو تحديد معدّل لكل عميل، أو التحقّق من الطلبات، أو التخزين المؤقت للاستجابات، أو AWS WAF.
لأن الموقع يُقدَّم من https://lantern.example والـ API يعيش على نطاق آخر، اضبط CORS على الـ HTTP API للسماح بذلك الـ origin، أو أضف الـ API كـ origin ثانٍ في الـ distribution الخاص بـ CloudFront تحت /api/* كي يرى المتصفّح نطاقًا واحدًا. ثم اختبر:
curl -i -X POST \\\n \"https://a1b2c3d4e5.execute-api.eu-west-1.amazonaws.com/events/evt-2026-street-food/rsvps\" \\\n -H \"content-type: application/json\" \\\n -d '{\"email\":\"rita@example.com\",\"name\":\"Rita\"}'يعيد الاستدعاء الأول 201؛ أرسله مرة أخرى فتحصل على 409.
كل قطعة تُحتسب حسب الاستخدام: API Gateway لكل طلب، وLambda لكل طلب ولكل GB-second، وDynamoDB بنمط on-demand لكل قراءة وكتابة. الأسبوع الهادئ لا يكاد يكلّف شيئًا، وأمسية المهرجان تكلّف ما يعادل بضعة آلاف من الطلبات. وللتأكّد من أن بوتًا لا يستطيع تضخيم الفاتورة أو إغراق أي شيء في المراحل التالية، اضبط reserved concurrency على الدالة (سقف لعدد النسخ المتزامنة) وحدًّا للمعدّل (throttling) على مرحلة الـ API.
\nفي الدرس التالي ستراقب هذا الـ API في الإنتاج: السجلات والمقاييس والإنذارات، ومراجعة منظّمة للتصميم كله.
\n","toc":[{"id":"sec-1","text":"الصورة العامة","level":2},{"id":"sec-2","text":"الدالة","level":2},{"id":"sec-3","text":"الصلاحيات","level":2},{"id":"sec-4","text":"الـ API","level":2},{"id":"sec-5","text":"كم يكلّف، وكيف تضع له سقفًا","level":2}],"takeaways":["يستقبل الـ HTTP API في API Gateway الطلب، ويستدعي Lambda بحدث JSON، ويعيد أيّ رمز حالة ومحتوى تعيدهما الدالة.","تحتاج دالة Lambda إلى نوعين من الصلاحيات؛ الـ execution role يتيح لها استدعاء DynamoDB، وسياستها القائمة على المورد تتيح لـ API Gateway استدعاءها.","الكتابة المشروطة مثل attribute_not_exists تمنع النقرات المزدوجة وإعادة المحاولات من إنشاء عناصر مكرّرة.","اختر HTTP APIs للـ APIs البسيطة منخفضة التكلفة، وREST APIs حين تحتاج إلى API keys، أو تحديد معدّل لكل عميل، أو التحقّق من الطلبات، أو التخزين المؤقت، أو AWS WAF.","كل قطعة تُحتسب لكل طلب، فالـ API الخامل لا يكاد يكلّف شيئًا، والـ reserved concurrency يضع سقفًا لمدى توسّع الذروة."],"further":[{"title":"Choose between REST APIs and HTTP APIs","url":"https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-vs-rest.html"},{"title":"Create AWS Lambda proxy integrations for HTTP APIs","url":"https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-develop-integrations-lambda.html"},{"title":"Condition expressions in DynamoDB","url":"https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Expressions.ConditionExpressions.html"},{"title":"Tutorial: Create a CRUD HTTP API with Lambda and DynamoDB","url":"https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-dynamo-db.html"}],"quiz":[{"q":"تعمل الدالة عند اختبارها في console الـ Lambda، لكن الاستدعاءات عبر API Gateway تفشل لأن API Gateway غير مسموح له باستدعائها. ما الناقص؟
","options":[{"text":"عبارة في الـ execution role الخاص بالدالة تسمح بـapigateway:*.","why":"يتحكّم الـ execution role فيما تستطيع الدالة استدعاءه، لا فيمن يستطيع استدعاء الدالة."},{"text":"سياسة لجدول DynamoDB تسمّي API Gateway.","why":"لا يتحدّث API Gateway إلى DynamoDB أبدًا في هذا التصميم؛ إنه يستدعي الدالة فقط."},{"text":"مستخدم IAM لـ API Gateway مع مفتاح وصول.","why":"تعمل خدمات AWS عبر service principals وroles، ولا تعمل أبدًا عبر مستخدمي IAM بمفاتيح."},{"text":"عبارة في السياسة القائمة على المورد الخاصة بالدالة تسمح لـ apigateway.amazonaws.com باستدعاء lambda:InvokeFunction لهذا الـ API.","why":"صحيح. من يحق له استدعاء الدالة يُحدَّد في سياستها القائمة على المورد، مقيّدًا بـ source ARN لهذا الـ API."}],"answer":3},{"q":"نقر أحد المنظّمين على زر الإرسال مرتين، فوصل طلبا تأكيد حضور متطابقان خلال أجزاء من الألف من الثانية. كيف تتجنّب دالة الدرس تخزين تأكيدَي حضور؟
","options":[{"text":"يستخدمPutItem العبارة ConditionExpression attribute_not_exists(email)، فتفشل الكتابة الثانية بـ ConditionalCheckFailedException وتعيد 409.","why":"صحيح. يتحقّق DynamoDB من الشرط بشكل ذرّي (atomic) على العنصر، فتنجح كتابة واحدة بالضبط من الاثنتين."},{"text":"يزيل API Gateway الطلبات المكرّرة تلقائيًا.","why":"يمرّر API Gateway كل طلب يستقبله. إزالة التكرار مهمة التطبيق."},{"text":"تشغّل Lambda نسخة واحدة فقط من الدالة في كل مرة.","why":"تشغّل Lambda نسخًا بعدد الطلبات المتزامنة، فيمكن أن يعمل الطلبان في الوقت نفسه."}],"answer":0},{"q":"يحتاج Lantern إلى API keys كي يستطيع موقعان شريكان إرسال تأكيدات الحضور، لكلٍّ منهما حد استخدام خاص به. أيّ نوع من API Gateway يناسب ذلك؟
","options":[{"text":"HTTP API، لأنه أرخص.","why":"الـ HTTP APIs أرخص لأنها تستغني عن بعض الميزات، والـ API keys مع خطط الاستخدام (usage plans) من بينها."},{"text":"WebSocket API، لأن الشريكين يحتاجان إلى اتصال حي.","why":"الـ WebSocket APIs للاتصالات ثنائية الاتجاه طويلة الأمد، والشريكان اللذان يرسلان نماذج لا يحتاجان إلى ذلك."},{"text":"REST API، الذي يدعم API keys مع خطط الاستخدام وتحديد المعدّل لكل عميل.","why":"صحيح. حين تحتاج إلى ميزات إدارة الـ API هذه، فنوع REST API هو الذي يوفّرها."}],"answer":2}],"exercise":{"kind":"spot-bug","language":"js","code":"import { DynamoDBClient } from \"@aws-sdk/client-dynamodb\";\nimport { DynamoDBDocumentClient, PutCommand, ScanCommand } from \"@aws-sdk/lib-dynamodb\";\n\nconst db = DynamoDBDocumentClient.from(new DynamoDBClient({\n credentials: { accessKeyId: \"AKIAIOSFODNN7EXAMPLE\", secretAccessKey: process.env.SECRET },\n}));\nconst TABLE = process.env.TABLE_NAME;\n\nconst reply = (statusCode, data) => ({\n statusCode,\n headers: { \"content-type\": \"application/json\" },\n body: JSON.stringify(data),\n});\n\nexport const handler = async (event) => {\n const eventId = event.pathParameters?.eventId;\n\n if (event.requestContext.http.method === \"GET\") {\n const res = await db.send(new ScanCommand({\n TableName: TABLE,\n FilterExpression: \"eventId = :e\",\n ExpressionAttributeValues: { \":e\": eventId },\n }));\n return reply(200, { eventId, count: res.Items.length });\n }\n\n const { email, name } = JSON.parse(event.body ?? \"{}\");\n if (typeof email !== \"string\" || !email.includes(\"@\")) {\n return reply(400, { error: \"A valid email is required\" });\n }\n\n try {\n await db.send(new PutCommand({\n TableName: TABLE,\n Item: { eventId, email: email.toLowerCase(), name },\n ConditionExpression: \"attribute_exists(email)\",\n }));\n } catch (err) {\n if (err.name === \"ConditionalCheckFailedException\") {\n return reply(409, { error: \"You have already RSVPed to this event\" });\n }\n throw err;\n }\n return reply(201, { eventId, email });\n};","bugLines":[5,19,36],"title":"راجع دالة تأكيد الحضور","prompt":"فُتح pull request بهذه النسخة من lantern-rsvp. تبدو مطابقة لدالة الدرس إلى حد كبير، لكن ثلاثة أسطر فيها ستتسبّب في حادثة أمنية، أو فاتورة متضخّمة، أو تعطّل تأكيدات الحضور في الإنتاج. اخترها.
السطر 5 يثبّت مفتاح وصول داخل الـ client. للدالة execution role بالفعل، وتستخدمه الـ SDK تلقائيًا حين لا تمرّر أي بيانات اعتماد، لذا احذف الخيار credentials كليًا؛ ولا تضع المفاتيح في الكود أو متغيّرات البيئة أبدًا. السطر 19 يعدّ تأكيدات الحضور باستخدام Scan مع ترشيح، فيقرأ كل عنصر في الجدول ويحتسبه مع كل مشاهدة للصفحة؛ استخدم QueryCommand مع KeyConditionExpression: "eventId = :e" وSelect: "COUNT". (كما أن Scan يتوقّف بعد 1 MB، فيكون هذا العدّ في جدول كبير خاطئًا فضلًا عن كونه مكلفًا.) السطر 36 يعكس حارس التكرار: attribute_exists(email) يجعل الكتابة تنجح فقط حين يكون تأكيد الحضور موجودًا من قبل، فيفشل كل تأكيد حضور جديد بالرمز 409. يجب أن يكون attribute_not_exists(email).