Edge как часть приложения: персонализация и кэширование прямо на краю

Edge функции Next.js позволяют исполнять логику максимально близко к пользователю: редиректы, локализация, простая персонализация и выбор ближайших источников данных без похода в центральный бэкенд. В связке с CDN кешированием это даёт стабильный TTFB и предсказуемые Web Vitals. В статье — как мы проектируем ключи кэша, маршрутизацию и безопасность, чтобы Edge не превращался в «второй бэкенд».

1) Какие задачи решает Edge

Мы выносим на край то, что зависит от запроса и не требует «тяжёлых» данных: выбор локали/региона, AB-маршруты, переписывание путей, защита медиаконтента по подписи URL, быстрые ответы из локального кэша. Edge не должен держать долгие соединения и выполнять сложные агрегации — это работа BFF/бэкенда.

• Geo-routing: ближайший регион для SSR/ISR и API.
• Локализация и валюты: проставить куки/заголовки для фронта и BFF.
• Canary/blue-green: проценты трафика на новую версию/кластер.
• Подписанные ссылки на медиа: проверка сигнатуры и TTL.

2) Ключи кэша: локаль, регион, параметры

У кэша должен быть детерминированный ключ. Мы включаем в него локаль, регион, важные query-параметры и флаги. Для статики — immutable с версионированием; для динамики — понятные TTL и инвалидации по тегам. На уровне Edge запрещаем заголовки, которые ломают кеширование (vary «на всё»), и нормализуем URL (слеши, регистр).

Полезные правила

• Ключ = путь + локаль + регион + безопасные query; A/B-флаг — отдельный суффикс.
• Для ISR — двойной кэш: CDN на краю + серверный; инвалидации синхронизируем.
• Слои кэша документируем: где живёт TTL, кто инвалидирует, как наблюдать промахи.

3) Персонализация без «тяжёлых» данных

На краю уместна «лёгкая» персонализация: язык, валюта, экспериментальная ветка, тип пользователя по куке. Всё, что требует авторизации и приватных данных, делаем после загрузки страницы через BFF. Если нужна персонализация HTML, ограничиваемся небольшими фрагментами и короткими TTL, стримим остальное.

4) Безопасность Edge и медиа

Edge не хранит секреты долговременно. Подписанные URL генерирует бэкенд/BFF, край только проверяет сигнатуру и срок. CSP/Headers выставляются централизованно, редиректы и переписывания — с белыми списками. Для приватного контента используем токены доступа с коротким TTL и доп.проверки на сервере назначения.

5) Инвалидации и очереди

Самая сложная часть — убрать протухшее. Мы инвалидацируем по тегам и путям через API CDN, группируем события в очередь, избегая «штормов». Для массовых обновлений — батч; для критичных — точечная синхронная очистка. Важно видеть, сколько времени прошла инвалидация до края и какая доля запросов попала на старый контент.

6) Наблюдаемость и лимиты

Мы логируем промахи/попадания кэша, время до первого байта по регионам, процент трафика на эксперименты. Лимиты на Edge жёстче: время исполнения, память, ограничения I/O. Любые «долгие» операции — в BFF. Дашборды показывают здоровье по регионам и задержки до апстримов, чтобы вовремя «перекроить» маршрутизацию.

7) Анти-паттерны

• Тащить персональные данные пользователя на край — риск и юридические последствия.
• Ключи кэша без локали/региона — «перемешивание» языков и валют.
• Логика бизнес-домена в Edge — сложная эксплуатация и дебаг.
• Инвалидация «всё и сразу» — лавина промахов и перегрев бэкенда.

Итог: Edge-функции — это лёгкая логика маршрутизации/локализации и «умный» кэш, а не замена бэкенда. Мы используем край там, где он даёт максимум: гео-близость, предсказуемый TTFB и безопасную персонализацию. Смету и план внедрения обсудим по контактам на сайте.