Завантаження документації...
Підготовка контенту платформи Ring
Концепції, цінність і типові сценарії
Концепції, цінність і типові сценарії
Підготовка контенту платформи Ring
Підготовка контенту платформи Ring
Підготовка контенту платформи Ring
Стратегії профілювання та оптимізації, специфічні для Ring Platform. Цей документ охоплює реальні патерни кодової бази. Щодо очікувань продуктивності для користувачів див. Продуктивність. Щодо посилення продуктивності в продакшені див. Продуктивність розгортання. Щодо загальних конвенцій розробки див. Найкращі практики.
Ring Platform не використовує Firestore на стороні клієнта. Firebase використовується виключно через Admin SDK у lib/firebase-admin.server.ts. Єдиний клієнтський код Firebase — це public/firebase-messaging-sw.js для push-сповіщень FCM.
Ring Platform завантажується швидко, оскільки більшість сторінок — це серверні компоненти React, що рендеряться на сервері. Ключові фактори, що впливають на продуктивність:
cache() з React 19.| Оптимізація | Перевага |
|---|---|
| React 19 cache() | Дедуплікація читань Firestore на один запит |
| Імітація Firebase під час збірки | ~31% швидші збірки, запобігає 22+ зайвим ініціалізаціям |
| Рівень запитів DatabaseService | Уніфікований PostgreSQL + Firestore з кешуванням |
| Серверні компоненти за замовчуванням | Без клієнтського JS для більшості сторінок |
| WayForPay лише на сервері | Жодна логіка платежів не потрапляє на клієнт |
| FCM Service Worker | Push-сповіщення обробляються поза головним потоком |
Щодо очікувань продуктивності для користувачів див. Продуктивність (користувач). Щодо моніторингу продакшену та налаштування інфраструктури див. Продуктивність розгортання. Щодо загальних конвенцій розробки див. Найкращі практики.
Стратегії профілювання та оптимізації, специфічні для Ring Platform. Цей документ охоплює реальні патерни кодової бази. Щодо очікувань продуктивності для користувачів див. Продуктивність. Щодо посилення продуктивності в продакшені див. Продуктивність розгортання. Щодо загальних конвенцій розробки див. Найкращі практики.
Ring Platform не використовує Firestore на стороні клієнта. Firebase використовується виключно через Admin SDK у lib/firebase-admin.server.ts. Єдиний клієнтський код Firebase — це public/firebase-messaging-sw.js для push-сповіщень FCM.
Ring Platform завантажується швидко, оскільки більшість сторінок — це серверні компоненти React, що рендеряться на сервері. Ключові фактори, що впливають на продуктивність:
cache() з React 19.| Оптимізація | Перевага |
|---|---|
| React 19 cache() | Дедуплікація читань Firestore на один запит |
| Імітація Firebase під час збірки | ~31% швидші збірки, запобігає 22+ зайвим ініціалізаціям |
| Рівень запитів DatabaseService | Уніфікований PostgreSQL + Firestore з кешуванням |
| Серверні компоненти за замовчуванням | Без клієнтського JS для більшості сторінок |
| WayForPay лише на сервері | Жодна логіка платежів не потрапляє на клієнт |
| FCM Service Worker | Push-сповіщення обробляються поза головним потоком |
Щодо очікувань продуктивності для користувачів див. Продуктивність (користувач). Щодо моніторингу продакшену та налаштування інфраструктури див. Продуктивність розгортання. Щодо загальних конвенцій розробки див. Найкращі практики.
Стратегії профілювання та оптимізації, специфічні для Ring Platform. Цей документ охоплює реальні патерни кодової бази. Щодо очікувань продуктивності для користувачів див. Продуктивність. Щодо посилення продуктивності в продакшені див. Продуктивність розгортання. Щодо загальних конвенцій розробки див. Найкращі практики.
Ring Platform не використовує Firestore на стороні клієнта. Firebase використовується виключно через Admin SDK у lib/firebase-admin.server.ts. Єдиний клієнтський код Firebase — це public/firebase-messaging-sw.js для push-сповіщень FCM.
Ring Platform завантажується швидко, оскільки більшість сторінок — це серверні компоненти React, що рендеряться на сервері. Ключові фактори, що впливають на продуктивність:
cache() з React 19.| Оптимізація | Перевага |
|---|---|
| React 19 cache() | Дедуплікація читань Firestore на один запит |
| Імітація Firebase під час збірки | ~31% швидші збірки, запобігає 22+ зайвим ініціалізаціям |
| Рівень запитів DatabaseService | Уніфікований PostgreSQL + Firestore з кешуванням |
| Серверні компоненти за замовчуванням | Без клієнтського JS для більшості сторінок |
| WayForPay лише на сервері | Жодна логіка платежів не потрапляє на клієнт |
| FCM Service Worker | Push-сповіщення обробляються поза головним потоком |
Щодо очікувань продуктивності для користувачів див. Продуктивність (користувач). Щодо моніторингу продакшену та налаштування інфраструктури див. Продуктивність розгортання. Щодо загальних конвенцій розробки див. Найкращі практики.
lib/database/DatabaseService.ts:74Усі сторінки в app/ є серверними компонентами, якщо вони не містять директиви 'use client'. Це усуває клієнтський JavaScript для більшості маршрутів. Клієнтські компоненти використовуються лише для:
Шукайте 'use client' у app/, щоб побачити повний перелік клієнтських компонентів.
Firebase Cloud Messaging повністю обробляється в Service Worker у public/firebase-messaging-sw.js. Push-події обробляються без пробудження головного потоку JavaScript. Клієнт лише реєструє Service Worker і передає FCM-токен на сервер.
Платіжні запити виконуються виключно на стороні сервера. Жодні облікові дані продавця WayForPay, HMAC-ключі або логіка платежів не потрапляють у браузер. Клієнт надсилає посилання на замовлення; сервер формує та верифікує всі платіжні дані. Див. Інтеграція WayForPay.
Використовуйте експорт force-dynamic, force-static або revalidate для кожної сторінки, щоб контролювати рендеринг:
Статична генерація є режимом за замовчуванням. Явно позначайте сторінки як force-dynamic, якщо вони відображають дані конкретного користувача.
Web Vitals збираються в продакшені. Налаштуйте відстеження аналітики в середовищі розгортання. Для аналізу під час збірки виконайте:
Модуль firebase-service-manager.ts також надає внутрішні метрики кешу:
import { getCachedDocument, getCachedCollection } from '@/lib/services/firebase-service-manager'
// Кілька викликів одного документа під час SSG зводяться до одного читання Firestore
const entity = await getCachedDocument('entities', 'abc123')
const sameEntity = await getCachedDocument('entities', 'abc123') // cache hit
// Запити колекцій також кешуються на один запит
const activeEntities = await getCachedCollection('entities', {
where: { field: 'status', operator: '==', value: 'active' },
orderBy: { field: 'createdAt', direction: 'desc' },
limit: 20
})
import { isBuildTime, getMockFirebaseServices } from '@/lib/firebase/build-mock.server'
if (isBuildTime()) {
const { mockDb, mockAuth } = getMockFirebaseServices()
// mockDb.collection('test').get() повертає порожні результати
// Облікові дані Firebase не потрібні під час збірки
}
import { getDatabaseService } from '@/lib/database/DatabaseService'
const db = getDatabaseService()
const result = await db.query({
collection: 'entities',
filters: { status: 'active' },
orderBy: { field: 'createdAt', direction: 'desc' },
pagination: { limit: 20 }
})
if (!result.success) {
throw result.error || new Error('Query failed')
}lib/database/DatabaseService.ts:74Усі сторінки в app/ є серверними компонентами, якщо вони не містять директиви 'use client'. Це усуває клієнтський JavaScript для більшості маршрутів. Клієнтські компоненти використовуються лише для:
Шукайте 'use client' у app/, щоб побачити повний перелік клієнтських компонентів.
Firebase Cloud Messaging повністю обробляється в Service Worker у public/firebase-messaging-sw.js. Push-події обробляються без пробудження головного потоку JavaScript. Клієнт лише реєструє Service Worker і передає FCM-токен на сервер.
Платіжні запити виконуються виключно на стороні сервера. Жодні облікові дані продавця WayForPay, HMAC-ключі або логіка платежів не потрапляють у браузер. Клієнт надсилає посилання на замовлення; сервер формує та верифікує всі платіжні дані. Див. Інтеграція WayForPay.
Використовуйте експорт force-dynamic, force-static або revalidate для кожної сторінки, щоб контролювати рендеринг:
Статична генерація є режимом за замовчуванням. Явно позначайте сторінки як force-dynamic, якщо вони відображають дані конкретного користувача.
Web Vitals збираються в продакшені. Налаштуйте відстеження аналітики в середовищі розгортання. Для аналізу під час збірки виконайте:
Модуль firebase-service-manager.ts також надає внутрішні метрики кешу:
import { getCachedDocument, getCachedCollection } from '@/lib/services/firebase-service-manager'
// Кілька викликів одного документа під час SSG зводяться до одного читання Firestore
const entity = await getCachedDocument('entities', 'abc123')
const sameEntity = await getCachedDocument('entities', 'abc123') // cache hit
// Запити колекцій також кешуються на один запит
const activeEntities = await getCachedCollection('entities', {
where: { field: 'status', operator: '==', value: 'active' },
orderBy: { field: 'createdAt', direction: 'desc' },
limit: 20
})
import { isBuildTime, getMockFirebaseServices } from '@/lib/firebase/build-mock.server'
if (isBuildTime()) {
const { mockDb, mockAuth } = getMockFirebaseServices()
// mockDb.collection('test').get() повертає порожні результати
// Облікові дані Firebase не потрібні під час збірки
}
import { getDatabaseService } from '@/lib/database/DatabaseService'
const db = getDatabaseService()
const result = await db.query({
collection: 'entities',
filters: { status: 'active' },
orderBy: { field: 'createdAt', direction: 'desc' },
pagination: { limit: 20 }
})
if (!result.success) {
throw result.error || new Error('Query failed')
}lib/database/DatabaseService.ts:74Усі сторінки в app/ є серверними компонентами, якщо вони не містять директиви 'use client'. Це усуває клієнтський JavaScript для більшості маршрутів. Клієнтські компоненти використовуються лише для:
Шукайте 'use client' у app/, щоб побачити повний перелік клієнтських компонентів.
Firebase Cloud Messaging повністю обробляється в Service Worker у public/firebase-messaging-sw.js. Push-події обробляються без пробудження головного потоку JavaScript. Клієнт лише реєструє Service Worker і передає FCM-токен на сервер.
Платіжні запити виконуються виключно на стороні сервера. Жодні облікові дані продавця WayForPay, HMAC-ключі або логіка платежів не потрапляють у браузер. Клієнт надсилає посилання на замовлення; сервер формує та верифікує всі платіжні дані. Див. Інтеграція WayForPay.
Використовуйте експорт force-dynamic, force-static або revalidate для кожної сторінки, щоб контролювати рендеринг:
Статична генерація є режимом за замовчуванням. Явно позначайте сторінки як force-dynamic, якщо вони відображають дані конкретного користувача.
Web Vitals збираються в продакшені. Налаштуйте відстеження аналітики в середовищі розгортання. Для аналізу під час збірки виконайте:
Модуль firebase-service-manager.ts також надає внутрішні метрики кешу:
import { getCachedDocument, getCachedCollection } from '@/lib/services/firebase-service-manager'
// Кілька викликів одного документа під час SSG зводяться до одного читання Firestore
const entity = await getCachedDocument('entities', 'abc123')
const sameEntity = await getCachedDocument('entities', 'abc123') // cache hit
// Запити колекцій також кешуються на один запит
const activeEntities = await getCachedCollection('entities', {
where: { field: 'status', operator: '==', value: 'active' },
orderBy: { field: 'createdAt', direction: 'desc' },
limit: 20
})
import { isBuildTime, getMockFirebaseServices } from '@/lib/firebase/build-mock.server'
if (isBuildTime()) {
const { mockDb, mockAuth } = getMockFirebaseServices()
// mockDb.collection('test').get() повертає порожні результати
// Облікові дані Firebase не потрібні під час збірки
}
import { getDatabaseService } from '@/lib/database/DatabaseService'
const db = getDatabaseService()
const result = await db.query({
collection: 'entities',
filters: { status: 'active' },
orderBy: { field: 'createdAt', direction: 'desc' },
pagination: { limit: 20 }
})
if (!result.success) {
throw result.error || new Error('Query failed')
}
// Статична сторінка, ревалідується кожні 60 секунд
export const revalidate = 60
// Повністю динамічна — без кешування
export const dynamic = 'force-dynamic'
npm run build
npm run analyze
import { getCacheMetrics } from '@/lib/services/firebase-service-manager'
const metrics = getCacheMetrics()
console.log(`Hit rate: ${metrics.hitRate.toFixed(1)}%`)
// Статична сторінка, ревалідується кожні 60 секунд
export const revalidate = 60
// Повністю динамічна — без кешування
export const dynamic = 'force-dynamic'
npm run build
npm run analyze
import { getCacheMetrics } from '@/lib/services/firebase-service-manager'
const metrics = getCacheMetrics()
console.log(`Hit rate: ${metrics.hitRate.toFixed(1)}%`)
// Статична сторінка, ревалідується кожні 60 секунд
export const revalidate = 60
// Повністю динамічна — без кешування
export const dynamic = 'force-dynamic'
npm run build
npm run analyze
import { getCacheMetrics } from '@/lib/services/firebase-service-manager'
const metrics = getCacheMetrics()
console.log(`Hit rate: ${metrics.hitRate.toFixed(1)}%`)