البنية
ما هي
تشرح هذه الصفحة البنية المشتركة الحالية legacy-shared. الرسوم ومسار الطلب أدناه يصفان هذا النطاق.
بوابة واحدة على خادمك تستقبل كل طلب، وتتحقق من مفتاح API، ثم تمرّره إلى خدمة Supabase الأصلية في البيئة الصحيحة. لكل بيئة قاعدة بياناتها وAuth وREST خاصة بها؛ أما PostgreSQL نفسه وStorage فعمليتان مشتركتان.
لماذا
الخيار هو مشاركة المحركات الثقيلة (PostgreSQL وStorage)، وفصل الخدمات التي تحمل هوية البيئة وواجهتها البرمجية (Auth وPostgREST وقاعدة البيانات وحسابات دخولها). Auth وPostgREST خدمتان صغيرتان، وتشغيلهما لكل بيئة يعني ألا تبديل لقاعدة البيانات لحظة الطلب، ولا نسخة معدّلة (fork) من أيٍّ منهما.
بدائل مرفوضة:
- Auth واحد وPostgREST واحد لكل البيئات، مع تبديل قاعدة البيانات في كل طلب. لا تدعم أيٌّ من الخدمتين الأصليتين هذا نمطًا معتمدًا، وجعله يعمل يعني إعادة كتابة كود حساس أمنيًا.
- حزمة كاملة لكل بيئة. أبقيناها أساسًا لقياس العزل وخيارًا احتياطيًا (PostgreSQL مستقل لكل بيئة)، لكنها تكرر كل المكوّنات.
كيف بنيناه
يعمل PostgreSQL وStorage مرة واحدة، وتضيف كل بيئة قاعدتها ومستأجر Storage وAuth وREST صغيرين خاصين بها.
تفحص البوابة كل طلب مقابل البيئة المذكورة في مساره، وترفض بدل أن تضعه في طابور.
وهذا التوجيه الكامل، بما فيه مسار الإدارة وعامل التجهيز:
وكيل واحد، وخادم محلي واحد، وثلاثة مسارات.
مسار الطلب. يستدعي التطبيق /<environment>/rest/v1/... بمفتاحه العام، ويجوز لخادم أن يرسل مفتاحًا سريًا بدلًا منه. تقرأ البوابة سجل توجيه البيئة (هل هي في الصيانة؟ وأين تعمل؟)، وتطابق المفتاح مع البصمات المحفوظة، وتقبل الطلب إن كان عدد الطلبات الجارية للبيئة دون حدها المتزامن، وتحدّ الجسم بـ1 MiB (أما رفع ملف إلى Storage فيمر كما يصل حتى حد الرفع، 50 MiB افتراضيًا)، ثم تمرّره إلى PostgREST الخاص بتلك البيئة. طلبات Storage تذهب إلى عملية Storage المشتركة الوحيدة، مع ترويسة مستأجر موثوقة تسمّي البيئة. ومقابس Realtime واستدعاءات Edge Functions تسلك المسار نفسه إلى حاويات البيئة الخاصة بها. ولا تمرّر البوابة دون مفتاح API إلا تنزيلات Storage العامة والموقّعة، وخطوات Auth التي يصلها المتصفح برابط (verify وauthorize وcallback)، والدوال المنشورة مع إطفاء verify_jwt.
مسار الإدارة. يسجّل المشغّلون دخولهم عبر نطاق إدارة مخصص في Auth، لا يكون أبدًا Auth الخاصة ببيئة تطبيق. تستخرج واجهة التحكم هوية الفاعل من هذا الدخول، لا من جسم الطلب أبدًا، وتطبّق أدوار المالك والمدير والمشاهد. ويصل الوكلاء إلى واجهة التحكم نفسها عبر /v1 و/mcp برمز وصول شخصي، فيعملون باسم من أنشأه (وكلاء الذكاء الاصطناعي).
حدود الثقة. وكيل TLS وحده يواجه الشبكة؛ والخادم المحلي (loopback) وكل حاوية خلفه تستمع على loopback أو على شبكات Docker داخلية، بلا منافذ منشورة. حركة التطبيقات لا تدخل إلا عبر البوابة وتحتاج إلى مفتاح API لتلك البيئة؛ وحركة المشغّلين لا تمر إلا عبر نطاق الإدارة المنفصل وواجهة التحكم. مشغّلو الخادم موثوقون، وزوار التطبيقات غير موثوقين. ما يعنيه ذلك للمكوّنات المشتركة مشروح في العزل والثقة.
العمل في الخلفية. إنشاء بيئة يضع مهمة في الطابور. عامل تجهيز واحد، يمسك قفلًا حصريًا، ينشئ قاعدة البيانات وحسابات الدخول المحصورة، ويكتب قواعد الاتصال، ويشغّل الخدمات. انظر التجهيز.
| مشترك | منفصل لكل بيئة |
|---|---|
| محرك PostgreSQL (عنقود واحد) | قاعدة البيانات، وثلاثة حسابات دخول محصورة للخدمات، وقواعد الاتصال |
| عملية Storage | مستأجر Storage ومفاتيح توقيعه وبياناته الوصفية |
| البوابة وواجهة التحكم | Auth وPostgREST والمفاتيح العامة والسرية وسجل التوجيه |
| المفتاح الجذري لـVault | حاويات Realtime وEdge Functions وStudio، عند تشغيلها |
| معالج الخادم وذاكرته وقرصه | حدود فئة الموارد لكل حاوية |
الكود: src/control/application.ts (التوجيه بين المسارات الثلاثة)، وsrc/gateway/handler.ts وsrc/gateway/managed.ts (البوابة)، وsrc/gateway/concurrency.ts (القبول)، وsrc/control/http.ts وsrc/control/key-http.ts (واجهة الإدارة)، وsrc/control/catalog.ts (الفهرس)، وlab/worker.py وlab/durable_runtime.py (بيئة التشغيل). المسارات مسرودة في مرجع API.
مسار تجريبي لمحرك مستقل
تحدد مواصفة مكان التشغيل الأصلي بنية native-dedicated تستخدم صورة Supabase الأصلية لمحرك مستقل. يربط التصريح في فهرس التحكم هوية البيئة بقاعدة التطبيق وقاعدة الصيانة، مع الفصل بينهما. قبول هذا التصريح للقراءة لا يفعّل التجهيز أو التوجيه أو الاستعادة أو كل الخدمات المستهلكة له.
تسجّل خطة المنتج وسجل الأدلة الأجزاء المتحقق منها والفجوات. توقف فحص المهام المجدولة وطلبات HTTP عند اختلاف صلاحيات دوال cron الفعلية عن النموذج المتوقع، قبل تشغيل تلك المهام والطلبات. ولم يُقبل هذا المسار. وهذا المسار التجريبي لا يغيّر حدود البنية المشتركة الموصوفة هنا.
الحدود
- القبول لكل عملية بوابة، بلا طابور: البيئة المثقلة تأخذ
429، والخادم المشغول يأخذ503. عمليات البوابة المتعددة لا تتشارك العدّادات. - يمر رفع الملفات كما يصل حتى حد الرفع (50 MiB افتراضيًا)؛ والرفع القابل للاستئناف (TUS) لا يُوجَّه بعد.
- يعمل Realtime وEdge Functions في حاوية لكل بيئة تشغّلهما، ويعمل Studio لكل بيئة عند الطلب. أما مجمّع الاتصالات (pooler) وcron فلم يدخلا بعدُ في البنية العاملة.
- كل العمليات تتشارك فهرسًا محليًا واحدًا؛ ولا تنسيق بين عدة خوادم.
للتعمق
- طبقة التحكم، والتوجيه الدائم، وحمل البوابة الزائد، وتصريف البوابة.
- بيئة التشغيل المشتركة وسياسة الموارد.
- مواصفة دمج Studio: كيف يشغّل المشغّل Studio الأصلي لكل بيئة عند الطلب.