اليوم الذي حاولت فيه بناء نظام خلفي قبل تناول القهوة
هل حاولت يومًا إنشاء نظام خلفي صباح يوم الاثنين—لتدرك أن بوابة واجهة برمجة التطبيقات الخاصة بك تقضي إجازة في حالة 403 Forbidden وأن قاعدة بياناتك تعاني من مشاكل في الالتزام؟ لقد كنت أنا ذلك الشخص ذات مرة. أردت نقطة نهاية صغيرة—مجرد /hello لطيفة—وبطريقة ما انتهى بي الأمر بمناقشة VPCs كما لو كنت أختار منزلًا في Hogwarts.
إليك الخبر السار: Lovable Cloud يحاول جعل جزء "بناء نظام خلفي"…حسنًا…محبوبًا. أو على الأقل أقل إثارة للغضب. إذا كان لديك 30 دقيقة واتصال Wi-Fi وقدرة على تحمل عدد قليل من الاستعارات، فسأشرح لك كيفية إنشاء نظام خلفي باستخدام Lovable Cloud—خطوة بخطوة، وما يجب الانتباه إليه، وكيفية منعه من التحول إلى وعاء سباغيتي من نقاط النهاية.
تنبيه: هذا دليل عملي وتطبيقي. أقل شعرًا للبائع، وأكثر "انقر هنا، واكتب هذا، ولا تفعل ذلك." ونعم، سنقوم بشحن شيء حقيقي: واجهة برمجة تطبيقات تعمل مع مصادقة وقاعدة بيانات وأسرار بيئية ونشر ومراقبة ومسار سريع للتوسع. أحضر وجبة خفيفة. نحن نشحن.
ما هو Lovable Cloud ولماذا يجب أن يهتم نظامك الخلفي؟
فكر في Lovable Cloud على أنه سكين الجيش السويسري الحديث للنظام الخلفي: وظائف بدون خادم، وتوجيه واجهة برمجة التطبيقات، واتصالات قاعدة البيانات، والأسرار البيئية، وCI/CD—كل ذلك يهدف إلى تجنيبك الحفاظ على حديقة حيوانات ياميل المتربة.
- أنت تكتب التعليمات البرمجية (Node/TypeScript، Python—راجع الوثائق لمعرفة ما هو رائج الآن).
- أنت تحدد المسارات (REST). إذا كنت تتوهم، يمكنك إضافة GraphQL أو الالتزام بـ JSON.
- أنت تربط قاعدة بيانات مُدارة (PostgreSQL هي حبيبة المدرسة الثانوية النموذجية هنا).
- أنت تنشر. إنه يتوسع. تتوقف عن القلق بشأن الاستيقاظ في الساعة 3 صباحًا لإضافة المزيد من الخوادم.
إذا كان نموذجك الذهني لـ "النظام الخلفي" هو: نقاط النهاية + المصادقة + البيانات + النشر + السجلات، فإن Lovable Cloud يحاول أن يكون المسار السريع مع عدد أقل من الصفارات والمزيد من الإيصالات.
خطة اللعبة لبناء نظام خلفي باستخدام Lovable Cloud
- إنشاء مشروع ومستودع Lovable Cloud.
- إنشاء واجهة برمجة تطبيقات مع مسار عام ومسار محمي.
- إضافة قاعدة بيانات PostgreSQL وتشغيل ترحيل.
- توصيل متغيرات البيئة وORM بسيط.
- إضافة مصادقة (JWT، أو رموز الجلسة، أو OAuth—الخيار لك).
- إضافة مراقبة/تسجيل واختبار آلي واحد.
- الترقية إلى الإنتاج دون كسر قلب مستقبلك.
نعم، يبدو الأمر كثيرًا. لا، لن يستغرق الأمر أسبوعًا كاملاً.
الخطوة 1: تشغيل مشروع Lovable Cloud الخاص بك (المعروف أيضًا باسم رائحة المشروع الجديد)
- أنشئ حسابًا وابدأ مشروعًا جديدًا. أطلق عليه اسمًا ستتعرف عليه لاحقًا—"not_final_backend_v7" هو فخ.
- اختر وقت التشغيل الخاص بك (Node/TypeScript هو عادةً الأكثر إرضاءً للجماهير لواجهات برمجة التطبيقات).
- اختر قالبًا إذا كان متاحًا: "REST API" أو "وظائف بدون خادم" يوصلك إلى اللون الأخضر أسرع من الخوف من الصفحة الفارغة.
ستحصل على مستودع Git (خاص بك أو بهم) وبيئة تطوير. نقاط إضافية إذا قمت بالتفرع على الفور ("feature/hello-api") حتى لا يصبح فرعك الرئيسي متحفًا حيًا للأخطاء.
الخطوة 2: إنشاء أول نقطة نهاية لك (لأن Hello World لا تزال رائعة)
إنشاء مسار أساسي: /api/hello. حافظ عليه غبيًا وسعيدًا.
- ملف المسار:
routes/hello.ts
- الوظيفة: تُرجع JSON مثل
{ message: "Hello, world" }
- الاختبار محليًا: cURL أو عميل HTTP المفضل لديك. إذا لم تحصل على 200، فتراجع عن خطواتك وتحقق من السجلات.
نصيحة احترافية: حافظ على معالجات المسار الخاصة بك نحيفة—لا توجد منطق أعمال داخل نقطة النهاية. ضع المنطق في الخدمات. عمليات إعادة البناء المستقبلية الخاصة بك ستشكرك.
الخطوة 3: إضافة قاعدة بيانات دون استدعاء أرواح DevOps القديمة
اختر PostgreSQL. إنه موثوق وعلائقي وليس لديه حساسية تجاه عمليات الربط.
- في Lovable Cloud، قم بإنشاء مثيل Postgres مُدار.
- تخزين بيانات الاعتماد كمتغيرات بيئية:
DATABASE_URL، DB_USER، DB_PASS، DB_HOST، DB_NAME.
- اختر ORM أو منشئ استعلام (Prisma، Drizzle، Knex). أنا متحيز تجاه Prisma لسرعته وسلامة المخطط.
إنشاء جدول users صغير لإثبات أنه يعمل:
- المخطط:
id (uuid)، email (unique)، created_at (timestamp).
- تشغيل الترحيل من بيئة التطوير الخاصة بك.
- اكتب نقطة نهاية
GET /api/users تُرجع قائمة. أضف POST /api/users لإدراج واحدة جديدة. احمها بالمصادقة (الخطوة التالية)، ولكن في الوقت الحالي، تحقق من خلال إدراج اختبار.
إذا كنت ترى مهلات أو إعادة تعيين الاتصال، فتحقق من: المنفذ الصحيح ووضع SSL وما إذا كانت بيئة التطوير الخاصة بك مسموحًا لها بالتحدث إلى قاعدة البيانات (قواعد VPC وقوائم السماح IP تحب الدراما).
الخطوة 4: إضافة مصادقة لا تجعل المستخدمين يبكون
لديك خيارات:
- مصادقة قائمة على JWT لواجهات برمجة التطبيقات عديمة الحالة
- رموز الجلسة مع ملفات تعريف الارتباط الآمنة (رائعة لتطبيقات الويب)
- OAuth مع Google وGitHub وما إلى ذلك (رائع لتجنب مطهر كلمة المرور)
لتحقيق فوز سريع، ابدأ بـ JWT:
- إنشاء رموز عند تسجيل الدخول (
POST /api/auth/login).
- تخزين سر التوقيع في مدير الأسرار الخاص بـ Lovable Cloud.
- إنشاء برنامج وسيط يقرأ عنوان
Authorization: Bearer <token>.
- حماية المسارات مثل
POST /api/users وأي شيء يقوم بتغيير البيانات.
تذكر: فترات صلاحية الرمز القصيرة + رموز التحديث = عدد أقل من الصداع عندما تضيع الأجهزة أو ينسى المطورون أنهم تركوا رمزًا في تعليق على YouTube (لا تسأل).
الخطوة 5: متغيرات البيئة: أسرار، وليست تذكارات
مركزية الأسرار باستخدام مدير البيئة الخاص بـ Lovable Cloud:
- مفاتيح واجهة برمجة تطبيقات الطرف الثالث (موفر البريد الإلكتروني والمدفوعات)
قم بتعيينها لكل بيئة (التطوير والاختبار والإنتاج). لا تقم بتضمين أي شيء في التعليمات البرمجية بشكل ثابت. لا تفعل. حتى "في الوقت الحالي فقط." هكذا تبدأ القصص المرعبة.
الخطوة 6: النشر في مرحلة الاختبار دون شرحها لمعالجك المستقبلي
انقر فوق نشر. شاهد السجلات. تنفس.
- التحقق من فحوصات السلامة: هل يُرجع الجذر أو
/api/health ok؟
- تشغيل اختبار الدخان:
GET /api/hello، GET /api/users.
- جرب مسارًا محميًا واحدًا باستخدام رمز اختبار—تأكد من 401 بدونه، و200 به.
إذا كانت البدايات الباردة بطيئة، فقم بتجميع الوظائف الصغيرة في خدمة واحدة حيث يكون ذلك منطقيًا. النظام بدون خادم رائع، ولكن 400 وظيفة صغيرة يمكن أن تكون أوركسترا بدون قائد.
الخطوة 7: إضافة مراقبة حتى لا تخمن في الساعة 2 صباحًا
- تمكين تسجيل الطلبات (سجلات منظمة، من فضلك).
- إعداد التقاط الأخطاء (تتبعات المكدس مع معرف الطلب).
- إضافة لوحات معلومات زمن الوصول. راقب p95، وليس فقط p50. لا يعاني المستخدمون من المتوسطات.
- إنشاء تنبيهات لارتفاعات 5xx وتقلب اتصال قاعدة البيانات.
سطر سجل واحد مع معرف الطلب في كل طبقة يساوي 10000 رسالة Slack تبدأ بـ "هل يرى أحد هذا؟"
الخطوة 8: كتابة اختبار واحد. ثم اثنان. ثم أتمتة.
ابدأ صغيرًا:
- اختبار الوحدة: وظيفة خدمة تتحقق من صحة رسائل البريد الإلكتروني أو تحسب الإجماليات.
- اختبار التكامل: استدعاء
/api/users باستخدام قاعدة بيانات اختبار.
توصيل CI لتشغيل الاختبارات على طلبات السحب. لا توجد عمليات دمج PR مع اختبارات حمراء. أنت لا تحتاج إلى ألف اختبار اليوم—فقط المسارات الهامة. مثل أحزمة الأمان.
الخطوة 9: الترقية إلى الإنتاج (نعم، بعناية)
- تجميد الرئيسي لمدة ساعة. قم بإجراء الإصلاحات على مرحلة الاختبار أولاً.
- ترقية البنية. قم بتشغيل اختبار الدخان بعد النشر.
- تمكين تحديد المعدل على نقاط النهاية العامة.
- إذا قمت بالتخزين المؤقت، فقم بتعيين TTLs عاقلة. إذا لم تقم بالتخزين المؤقت، فاستعد لأن تنظر إليك قاعدة البيانات بعيون متعبة.
إضافة خطة التراجع: أنت لا تجلب سوء الحظ من خلال وجود واحدة. أنت تتصرف كشخص بالغ.
نظام خلفي بسيط وحقيقي يمكنك شحنه في فترة ما بعد الظهر
دعنا نوصل مجموعة ميزات صغيرة—ولكنها حقيقية:
- عام
GET /api/hello (الصحة والسلامة).
- محمي
POST /api/users (إنشاء مستخدم) و GET /api/me (إرجاع المستخدم الذي تمت مصادقته).
GET /api/users/:id لعمليات البحث المباشرة.
- حذف بسيط:
DELETE /api/users/:id تبديل deleted_at.
إضافة تحديد المعدل إلى /api/auth/login حتى لا تستخدم الروبوتات نظامك الخلفي كتمارين رياضية.
ثم قم برش رسالة ترحيب عبر البريد الإلكتروني عبر مزود البريد الإلكتروني الخاص بك. حافظ على الرسالة معاملاتية وودودة—واحفظ التسويق لمسارات التسويق الفعلية.
الفخاخ الشائعة عند بناء نظام خلفي باستخدام Lovable Cloud
- الحالة المشتركة في النظام بدون خادم: لا تعتمد على ذاكرات التخزين المؤقت في الذاكرة بين الاستدعاءات. استخدم Redis (مُدار) أو قاعدة البيانات الخاصة بك.
- تكوين CORS مفقود: تعيين الأصول المسموح بها. تقييد نطاقات تطبيقك. لا تستخدم حرف بدل كامل في الإنتاج.
- بدايات باردة طويلة: تجميع التبعيات بذكاء، وتقليل الانتفاخ لكل وظيفة، أو دمج المسارات الساخنة.
- الاستعلامات غير المفهرسة: إذا كان
GET /api/users الخاص بك زحفًا، فأضف فهرسًا على email و created_at. يرسل لك مستقبلك الشكر.
- الإخفاقات الصامتة: قم دائمًا بتسجيل الأخطاء مع السياق. "حدث خطأ ما" ليس شعر DevOps.
كيفية هيكلة التعليمات البرمجية حتى لا تبكي لاحقًا
repositories/ أو db/ للوصول إلى البيانات
middlewares/ للمصادقة وتحديد المعدل والتحقق من صحة الإدخال
lib/ للمساعدين (البريد الإلكتروني والتشفير وواجهات برمجة تطبيقات الطرف الثالث)
حافظ على الوظائف نقية قدر الإمكان. ضع الآثار الجانبية على الحواف. هذا يجعل الاختبار سهلاً ويجعل تصحيح الأخطاء أقل شبهاً ببرنامج جريمة.
تعديلات الأداء التي تهم حقًا
- استخدم الترقيم على أي نقطة نهاية قائمة. القائم على المؤشر إذا كان لديك مجموعات بيانات كبيرة.
- أضف ETags أو رؤوس آخر تعديل لتجنب إعادة إرسال العالم في كل طلب.
- تخزين الاستجابات المحسوبة مؤقتًا للاستعلامات المكلفة.
- تجميع عمليات الكتابة عندما تستطيع. استعلامات N+1 هي بريق أخطاء الواجهة الخلفية—فهي تصل إلى كل مكان.
أساسيات الأمان التي لا يمكنك تجاهلها (حتى لو كنت تريد ذلك)
- التحقق من صحة الإدخال في كل مسار. يمنع مخطط JSON أو مكتبة التحقق من الصحة الهجمات المفاجئة.
- تشفير كلمات المرور باستخدام Argon2 أو bcrypt. لا تقم أبدًا بإنشاء التشفير الخاص بك. أبداً. رجاءً.
- تدوير المفاتيح والأسرار على جدول زمني. تذكيرات التقويم أرخص من الخروقات.
- استخدم أدوار قاعدة بيانات بأقل الامتيازات. لا تحتاج واجهة برمجة التطبيقات الخاصة بك إلى صلاحيات المستخدم المتميز—لا أحد يفعل ذلك.
التحقق من واقعية التسعير: خطط للنمو، وليس حرقة المعدة
يبدو النظام بدون خادم مجانيًا…حتى لا يكون كذلك. راقب:
- عقوبات البداية الباردة عندما تكون حركة المرور متقطعة.
- تكاليف الخروج لواجهات برمجة التطبيقات الثرثارة.
- الوظائف طويلة الأمد التي يجب أن تكون وظائف في الخلفية.
تعيين الميزانيات والتنبيهات. إذا أرسل لك المدير المالي الخاص بك رمز تعبيري ناري، فقد فات الأوان بالفعل.
عندما تحتاج إلى مستندات وأمثلة وفحص السلامة
أعيش بحقيقتين: ستنسى كيف قمت بتكوين شيء ما، وستحتاج إلى إعداده مرة أخرى في الساعة 11 مساءً. احتفظ بـ README في المستودع الخاص بك مع:
- الأوامر الشائعة (الترحيل والاختبارات والنشر)
- قائمة نقاط النهاية مع أمثلة للطلبات
اجعلها ودودة لـ New You في غضون ثلاثة أشهر—أو زميل الفريق الجديد الفعلي الأسبوع المقبل.
جدير بالذكر: اختصار للبحث ومراجعات التعليمات البرمجية
جدير بالذكر: إذا كنت تريد رأيًا ثانيًا حول خيارات الهندسة المعمارية أو لمقارنة أفضل الممارسات بسرعة، فيمكن أن يعمل Sider.AI مثل زميل الفريق الذي لا معنى له والذي يراجع خطتك، ويشير إلى الحالات الشاذة الغريبة، ويسلمك قائمة مرجعية قبل الشحن. لن ينقر على نشر نيابة عنك—ولكنه سيساعدك على تجنب سلسلة Slack "يا لا". مرجع سريع: قائمة التحقق من Lovable Cloud Backend الخاصة بك
- تم إنشاء المشروع وإعداد Git واستراتيجية الفرع
- إرجاع نقطة نهاية Hello JSON
- تم توفير قاعدة البيانات وتشغيل الترحيل وتوصيل ORM
- المصادقة في مكانها والأسرار في مدير البيئة
- تم نشر مرحلة الاختبار، والسجلات نظيفة، والمسارات المحمية تعمل
- المراقبة والتنبيهات ولوحات المعلومات الأساسية
- تم توصيل الاختبارات بـ CI، ولا توجد PRs حمراء
- طرح الإنتاج مع تحديد المعدل وخطة التراجع
ألصق هذا بشاشتك. أو قم بوشمه. (من فضلك لا تقم بوشمه.)
الخلاصة: اجعلها محبوبة بجعلها مملة (بطريقة جيدة)
النظام الخلفي المحبوب هو الذي يقوم بعمله بهدوء أثناء نومك. ابني بقطع مملة ومثبتة: نقاط نهاية HTTP ومصادقة نظيفة وقاعدة بيانات قوية ونشر معقول. يساعد Lovable Cloud من خلال إزالة دراما السقالات حتى تتمكن من التركيز على الأجزاء المهمة—منتجك ومستخدميك وربما حتى القهوة التي تخطيتها.
شحن /hello. أضف /users. شد البراغي. ثم اذهب وافعل أي شيء آخر حرفيًا بينما يدندن نظامك الخلفي. هذا ليس مجرد محبوب—هذه هي الحياة.
أسئلة وأجوبة مصغرة: السيناريوهات الواقعية
هل يمكنني مزج واجهات برمجة تطبيقات عامة وخاصة في نفس المشروع؟
نعم. استخدم البرامج الوسيطة لبوابات المسارات الخاصة وفصل الرموز/المفاتيح لحركة مرور من جهاز إلى جهاز. حافظ على النطاقات ضيقة.
ماذا لو كنت بحاجة إلى وظائف في الخلفية؟
قم بتشغيل وظائف مجدولة أو قائمة على قائمة الانتظار للعمل طويل الأمد (رسائل البريد الإلكتروني والتقارير والمزامنات). لا تمنع طلبات المستخدمين لإرسال الرسائل الإخبارية.
كيف يمكنني منع مرحلة الاختبار والإنتاج من تبادل الأسرار مثل المراهقين؟
بيئات منفصلة. أسرار منفصلة. حواجز حماية في CI بحيث لا تتسلل بيانات اعتماد مرحلة الاختبار أبدًا إلى بنى الإنتاج.
هل يمكنني البدء ببساطة والذهاب إلى الخدمات المصغرة الكاملة لاحقًا؟
قطعاً. ابدأ بشكل متجانس للسرعة. استخرج النقاط الساخنة عندما تقول مقاييسك "الآن"، وليس عندما يقول بودكاست "الخدمات المصغرة رائعة".
الخطوات التالية: خطتك لمدة 30 دقيقة
- 5 دقائق: إنشاء مشروع، اختيار قالب
- 10 دقائق: بناء
/api/hello، توصيل قاعدة البيانات، تشغيل الترحيل
- 10 دقائق: إضافة مصادقة JWT، حماية
POST /api/users
- 5 دقائق: النشر في مرحلة الاختبار، تشغيل اختبار الدخان
هذا كل شيء. لقد قمت للتو ببناء نظام خلفي باستخدام Lovable Cloud. إنه يعمل. إنه يتوسع. ولا يزال لديك وقت لإعادة تسخين قهوتك.
أسئلة متكررة
س1: هل Lovable Cloud جيد للمبتدئين الذين يقومون ببناء نظام خلفي؟
نعم—قوالبه ووظائفه بدون خادم ومدير البيئة الخاص به تجعل النظام الخلفي الأول أقل رعبًا. ابدأ بواجهة برمجة تطبيقات REST بسيطة، وأضف قاعدة بيانات، ثم قم بتركيب المصادقة. ستتعلم أنماطًا حقيقية دون مصارعة مركز بيانات.
س2: كيف يمكنني تأمين نظام Lovable Cloud الخلفي الخاص بي للإنتاج؟
استخدم JWT أو OAuth، وأغلق CORS، وخزن الأسرار في مدير البيئة. أضف حدود المعدل، وتحقق من صحة الإدخال في كل مسار، وراقب زمن الوصول p95 حتى تكتشف المشكلات قبل أن يفعل المستخدمون ذلك.
س3: ما هي قاعدة البيانات التي تعمل بشكل أفضل مع Lovable Cloud لواجهات برمجة تطبيقات REST؟
PostgreSQL هو الاختيار الموثوق به لمعظم التطبيقات، خاصة مع ORM مثل Prisma أو Drizzle. يتعامل مع البيانات العلائقية والمعاملات والفهرسة دون دراما، ويتوسع مع نمو حركة المرور.
س4: كيف يمكنني التعامل مع البدايات الباردة والأداء على الأنظمة الخلفية بدون خادم؟
قم بتجميع التبعيات بذكاء، وقم بتسخين المسارات الهامة، وتجنب مائة وظيفة صغيرة عندما تقوم خدمة واحدة بذلك. أضف التخزين المؤقت والترقيم، وشاهد زمن الوصول p95 لضبط ما يهم حقًا.
س5: هل يمكنني نشر مرحلة الاختبار والإنتاج بأسرار وعناوين URL منفصلة؟
قطعاً. قم بإنشاء بيئات منفصلة، وقم بتعيين DATABASE_URL و JWT_SECRET ومجالات مميزة، وقم بترقية الإصدارات للأمام. إنه يحافظ على الاختبار آمنًا وعمليات التراجع غير مؤلمة.
