قائمة التحقق قبل الإطلاق
راجع هذه القائمة قبل الانتقال إلى بيئة الإنتاج. كل بند يحيل إلى القسم المقابل أدناه.1
تكوين حماية إعادة التشغيل للنسخ المتعددة
المحوّل الافتراضي يعمل في الذاكرة فقط. إذا كنت تشغّل أكثر من عملية واحدة (عمال Gunicorn، PM2 cluster، Kubernetes)، فاضبط
SUPABASE_URL + SUPABASE_ANON_KEY أو استخدم RedisReplayAdapter. التفاصيل →2
متغيرات البيئة في مدير الأسرار
لا تُدرج مفاتيح API مباشرةً في الكود. استخدم
.env محلياً ومدير الأسرار في الإنتاج. التفاصيل →3
وجود نقطة نهاية للتحقق من الصحة
يجب ألا تُطلق عمليات مراقبة النظام إنشاء فواتير. أضف مسار
/health قبل مساراتك المدفوعة. التفاصيل →4
استجابات الأخطاء لا تكشف التفاصيل الداخلية
التقط أخطاء المزود وأعد استجابة 503 نظيفة — لا تعيد تتبع المكدس. التفاصيل →
5
السعر مقصود
يجب أن يعكس
priceSats قيمة حقيقية. بسعر 1 sat ≈ 0.06 لنقطة نهاية مميزة أمر معقول. لا تضبطه على 0 بالخطأ.6
مراقبة وقت التشغيل على نقطة نهاية الفاتورة
راقب استجابة 402 (وهي استجابة طبيعية وليست خطأً). تدعم أدوات مثل UptimeRobot توقعات رموز الحالة المخصصة.
7
تحديد معدل إنشاء الفواتير
كل طلب غير مصادق عليه يُنشئ فاتورة Lightning. بدون تحديد المعدل، يمكن لمهاجم استنفاد حصة الفواتير لدى مزودك مجاناً. أضف
express-rate-limit قبل النشر العلني. التفاصيل →هام: حماية إعادة التشغيل في الإنتاج
متغيرات البيئة
لا تُدرج المفاتيح مباشرةً في الكود. استخدم دائماً متغيرات البيئة:تسجيل المدفوعات (Supabase)
سجّل كل دفعة في Supabase للوحة تحكم إضافة VS Code والتحليلات:النشر على Cloudflare Workers
يعمل l402-kit API على Cloudflare Workers (عوازل V8، بدون تأخير في البداية). يُعاد تعيين مخزن إعادة التشغيل في الذاكرة مع كل عازل — لواجهات برمجة التطبيقات ذات الحركة العالية، استخدم Cloudflare KV أو Durable Objects لحماية إعادة التشغيل.Docker
حذف بيانات المستخدم
افتح نقطة نهاية للحذف تتيح للمستخدمين إزالة بياناتهم بشكل دائم. تتضمن واجهة l402-kit الخلفية/api/delete-data جاهزةً للاستخدام:
معالجة الأخطاء
التقط أخطاء المزود قبل أن تظهر كاستجابات 500 غير منسقة:- لا تُعد تتبعات المكدس إلى العملاء أبداً — سجّلها من جهة الخادم.
- انتهاء مهلة المزود (503) مؤقت — يمكن إعادة المحاولة بتراجع تدريجي.
- أخطاء الرمز (401) ليست مؤقتة أبداً — لا تُعد المحاولة تلقائياً، اطلب فاتورة جديدة.
- أخطاء تحديد المعدل (429) — أظهر حقل
retryAfterللمُستدعي.
تحديد المعدل
كل طلب غير مصادق عليه يُطلقcreateInvoice() على مزود Lightning الخاص بك. بدون تحديد المعدل، يمكن لأي شخص إغراق نقطة النهاية الخاصة بك واستنفاد حصة API لدى مزودك مجاناً — حتى دون دفع sat واحد.
أضف express-rate-limit قبل مسارات L402 الخاصة بك:
يتم تخطي العملاء الذين يدفعون بالفعل عبر دالة
skip — يُطبَّق الحد فقط على الطلبات غير المصادق عليها التي تُطلق إنشاء فاتورة جديدة. لا يُقيَّد الدافعون الشرعيون أبداً.نقطة نهاية التحقق من الصحة
أضف دائماً فحص صحة مجاني حتى لا تُطلق أدوات المراقبة إنشاء فواتير:المراقبة
المقاييس الرئيسية للتتبع:- معدل استجابة 402 — المعدل الأساسي الصحي مرتفع (معظم المُستدعين بحاجة إلى الدفع)
- معدل التحقق من المدفوعات — نسبة المكالمات المدفوعة مقارنةً بغير المدفوعة
- زمن استجابة المزود — يجب أن يكون
blink.createInvoice()< 500ms - محاولات إعادة التشغيل — الارتفاع المفاجئ يشير إلى هجمات إعادة استخدام الرمز
الأداء
- التحقق من الرمز هو O(1) — تشفير بحت، بدون قاعدة بيانات، بدون شبكة
- إنشاء الفاتورة (مسار 402) يستدعي واجهة برمجة تطبيقات مزود Lightning الخاص بك — أضف ذاكرة تخزين مؤقت إذا كنت تتوقع ضرب نفس نقطة النهاية بشكل متكرر قبل الدفع
- مخزن إعادة التشغيل هو
Setفي الذاكرة — لعمليات النشر متعددة النسخ، استبدله بـ Redis