إذا كنت قد عملت مع حزمة تطوير البرامج (SDK) لـ Firebase JS أو حِزم تطوير برامج أخرى لعملاء Firebase، من المرجّح أنّك familiarizado مع واجهة FirebaseApp
وكيفية استخدامها لإعداد نُسخ تطبيقك. لتسهيل العمليات المشابهة من جهة الخادم،
توفّر Firebase FirebaseServerApp
.
FirebaseServerApp
هو أحد أنواع FirebaseApp
المخصّص للاستخدام في بيئات FirebaseApp
. ويتضمّن أدوات لمواصلة جلسات Firebase
التي تمتد على نطاق العرض من جهة العميل (CSR) / العرض من جهة الخادم. يمكن أن تساعد هذه
الأدوات والاستراتيجيات في تحسين تطبيقات الويب الديناميكية التي تم إنشاؤها باستخدام Firebase و
نشرها في بيئات Google، مثل Firebase App Hosting.
استخدِم FirebaseServerApp
لإجراء ما يلي:
- تنفيذ الرمز البرمجي من جهة الخادم ضمن سياق المستخدم، على عكس Firebase Admin SDK الذي يمتلك حقوق الإدارة الكاملة
- فعِّل استخدام App Check في بيئات إعادة التحميل من الخادم (SSR).
- مواصلة جلسة Firebase Auth التي تم إنشاؤها في العميل
مراحل نشاط FirebaseServerApp
تعمل إطارات عمل العرض من جهة الخادم (SSR) وعمليات التشغيل الأخرى غير المستندة إلى المتصفّح، مثل
مشغّلو الخدمات في السحابة الإلكترونية، على تحسين وقت الإعداد من خلال إعادة استخدام الموارد على مستوى
عمليات التنفيذ المتعدّدة. تم تصميم FirebaseServerApp
لاستيعاب هذه
البيئات باستخدام آلية احتساب عدد الإحالات. إذا استدعى تطبيق initializeServerApp
باستخدام المَعلمات نفسها المستخدَمة في initializeServerApp
سابق، سيتلقّى مثيل FirebaseServerApp
نفسه الذي سبق أن تم بدءه. ويؤدي ذلك إلى تقليل الوقت غير الضروري الذي تستغرقه عملية الإعداد
وتخصيص الذاكرة. عند استدعاء deleteApp
على FirebaseServerApp
مثيل، يتم تقليل عدد الإحالات، ويتم تحرير المثيل بعد وصول عدد الإحالات إلى الصفر.
حذف نُسخ FirebaseServerApp
قد يكون من الصعب معرفة وقت استدعاء deleteApp
في FirebaseServerApp
مثيل، خاصةً إذا كنت تُجري العديد من العمليات غير المتزامنة في
الموازاة. يساعد حقل releaseOnDeref
في FirebaseServerAppSettings
في
تبسيط ذلك. في حال منح releaseOnDeref
إشارة إلى عنصر له
فترة صلاحية تتوافق مع نطاق الطلب (على سبيل المثال، عنصر "الرؤوس" لطلب SSR
)، سيقلل FirebaseServerApp
عدد الإشارات عندما يستردّ
الإطار العمل عنصر العنوان. يؤدي ذلك إلى تنظيف مثيل
FirebaseServerApp
تلقائيًا.
في ما يلي مثال على استخدام releaseOnDeref
:
/// Next.js
import { headers } from 'next/headers'
import { FirebaseServerAppSettings, initializeServerApp} from "@firebase/app";
export default async function Page() {
const headersObj = await headers();
appSettings.releaseOnDeref = headersObj;
let appSettings: FirebaseServerAppSettings = {};
const serverApp = initializeServerApp(firebaseConfig, appSettings);
...
}
استئناف الجلسات التي تمّت مصادقتها على العميل
عند بدء تشغيل مثيل من FirebaseServerApp
باستخدام رمز مميّز لـ Auth ID، فإنه
يسمح بربط جلسات المستخدمين التي تمّت مصادقتها بين بيئة المعالجة من جهة العميل (CSR) وبيئة المعالجة من جهة الخادم (SSR). إنّ نُسخ ملف برمجي من
حزمة تطوير البرامج (SDK) لـ Firebase Auth التي تمّت تهيئتها باستخدام عنصر FirebaseServerApp
يحتوي على
معرّف رمز مصادقة ستحاول تسجيل دخول المستخدم عند الإعداد بدون
حاجة التطبيق إلى استدعاء أيّ طُرق تسجيل دخول.
يتيح تقديم رمز تعريف Auth للتطبيقات استخدام أيّ من طرق تسجيل الدخول في Auth على العميل، ما يضمن استمرار الجلسة من جهة الخادم، حتى بالنسبة إلى methodsتلك طرق تسجيل الدخول التي تتطلّب تفاعل المستخدم. بالإضافة إلى ذلك، تتيح هذه الميزة تفريغ العمليات المكثفة على الخادم، مثل طلبات البحث في Firestore التي تمّت المصادقة عليها، ما من شأنه تحسين أداء عرض تطبيقك.
/// Next.js
import { initializeServerApp } from "firebase/app";
import { getAuth } from "firebase/auth";
// Replace the following with your app's
// Firebase project configuration
const firebaseConfig = {
// ...
};
const firebaseServerAppSettings = {
authIdToken: token // See "Pass client tokens to the server side
// rendering phase" for an example on how transmit
// the token from the client and the server.
}
const serverApp =
initializeServerApp(firebaseConfig,
firebaseServerAppSettings);
const serverAuth = getAuth(serverApp);
// FirebaseServerApp and Auth will now attempt
// to sign in the current user based on provided
// authIdToken.
استخدام App Check في بيئات إعادة التحميل من الخادم (SSR)
يعتمد فرض سياسة App Check على مثيل حزمة تطوير البرامج (SDK) لتطبيق App Check تستخدمه حِزم SDK لمنصّة Firebase
للاتصال داخليًا بـ getToken
. ويتم بعد ذلك تضمين الرمز المميّز الناتج في طلبات العميل المرسَلة
إلى جميع خدمات Firebase، ما يسمح للنظام الأساسي بالتحقق من صحة التطبيق.
ومع ذلك، لا يمكن بدء حزمة تطوير البرامج (SDK) لتطبيق "التحقّق من التطبيقات" في بيئات الخادم لأنّها تحتاج إلى متصفّح للوصول إلى أساليب تحليلية معيّنة لإثبات صحة التطبيق.
FirebaseServerApp
يقدّم بديلاً. إذا تم تقديم رمز مميّز لفحص التطبيقات
من إنشاء العميل أثناء بدء FirebaseServerApp
، ستستخدمه
حِزم تطوير البرامج (SDK) لمنتجات Firebase عند استدعاء خدمات Firebase، ما يُلغي الحاجة
إلى مثيل حزمة تطوير البرامج (SDK) لفحص التطبيقات.
/// Next.js
import { initializeServerApp } from "firebase/app";
// Replace the following with your app's
// Firebase project configuration
const firebaseConfig = {
// ...
};
const firebaseServerAppSettings = {
appCheckToken: token // See "Pass client tokens to the server side
// rendering phase" for an example on how transmit
// the token from the client and the server.
}
const serverApp =
initializeServerApp(firebaseConfig,
firebaseServerAppSettings);
// The App Check token will now be appended to all Firebase service requests.
تمرير الرموز المميّزة للعملاء إلى مرحلة العرض من جهة الخادم
لنقل الرموز المميّزة لـ Auth ID (والرموز المميّزة لـ App Check) التي تمّت مصادقتها من العميل إلى مرحلة العرض من جهة الخادم (SSR)، استخدِم عامل خدمة. يتضمن هذا النهج اعتراض طلبات الجلب التي تؤدي إلى بدء ميزة SSR وإرفاق الرموز المميّزة بعناوين الطلبات.
راجِع مقالة إدارة الجلسات باستخدام مهام الخدمة
للحصول على مرجع لتنفيذ مهمة خدمة "مصادقة Firebase". اطّلِع أيضًا على
التغييرات على الجانب الخادم
للاطّلاع على الرمز الذي يوضّح كيفية تحليل هذه الرموز من الرؤوس لاستخدامها في بدء FirebaseServerApp
.