إذا سبق لك استخدام حزمة تطوير البرامج (SDK) لمنصة Firebase بلغة JavaScript أو حِزم تطوير البرامج (SDK) الأخرى الخاصة بالعملاء في Firebase، من المحتمل أنّك على دراية بواجهة FirebaseApp
وكيفية استخدامها لإعداد مثيلات التطبيقات. لتسهيل العمليات المشابهة على الخادم، يوفّر Firebase FirebaseServerApp
.
FirebaseServerApp
هو نوع من FirebaseApp
يُستخدم في بيئات العرض من جهة الخادم (SSR). وتتضمّن أدوات لمواصلة جلسات 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
باستخدام رمز مميّز لمعرّف المصادقة، يتيح ذلك ربط جلسات المستخدمين الذين تمت مصادقتهم بين بيئات العرض من جهة العميل (CSR) والعرض من جهة الخادم (SSR). ستحاول مثيلات حزمة تطوير البرامج (SDK) الخاصة بخدمة Firebase Auth التي تمّت تهيئتها باستخدام عنصر FirebaseServerApp
يحتوي على رمز مميّز لتعريف الهوية في Auth تسجيل دخول المستخدم عند التهيئة بدون الحاجة إلى أن يستدعي التطبيق أي طرق لتسجيل الدخول.
يتيح تقديم رمز مميّز لمعرّف المصادقة للتطبيقات استخدام أي من طرق تسجيل الدخول في Auth على الجهاز، ما يضمن استمرار الجلسة على الخادم، حتى بالنسبة إلى طرق تسجيل الدخول التي تتطلّب تفاعل المستخدم. بالإضافة إلى ذلك، تتيح هذه الميزة نقل العمليات المكثّفة إلى الخادم، مثل طلبات البحث المصادَق عليها في 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) الخاصة بخدمة App Check تحتاج إلى متصفّح للوصول إلى إحصاءات استدلالية معيّنة من أجل التحقّق من التطبيق، لا يمكن تهيئتها في بيئات الخادم.
تقدّم السمة FirebaseServerApp
بديلاً. إذا تم توفير رمز مميّز من App Check من جهة العميل أثناء عملية تهيئة FirebaseServerApp
، ستستخدمه حِزم تطوير البرامج (SDK) الخاصة بمنتجات Firebase عند استدعاء خدمات Firebase، ما يلغي الحاجة إلى مثيل حزمة تطوير البرامج (SDK) الخاصة بخدمة App Check.
/// 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
.