Edge Runtime и ограничения

Edge Runtime в современных JavaScript-платформах (Vercel Edge Functions, Cloudflare Workers, Deno Deploy) представляет собой облегчённую среду исполнения, построенную вокруг Web API-стандарта, а не Node.js. Это принципиально меняет доступный инструментарий и напрямую влияет на совместимость библиотек, включая решения для сессий и шифрования, такие как Iron-based подходы.

Ключевая идея Edge Runtime — минимальная задержка и глобальное распределение исполнения. Однако за это приходится платить ограничениями окружения.


Чем Edge Runtime отличается от Node.js

Отсутствие Node.js API

В Edge Runtime недоступны привычные модули:

  • fs (работа с файловой системой)
  • net, tls (низкоуровневые сетевые соединения)
  • child_process
  • большинство встроенных Node.js библиотек

Это означает, что любые зависимости, опирающиеся на файловую систему или нативные биндинги, автоматически становятся несовместимыми.


Web Crypto вместо Node Crypto

Одно из ключевых отличий — криптография.

В Node.js используется:

  • crypto (Node API)

В Edge Runtime используется:

  • Web Crypto API (crypto.subtle)

Это важно для библиотек вроде iron-session, которые используют шифрование для защиты данных в cookie.

Разница проявляется в:

  • асинхронной модели (Promise вместо синхронных вызовов)
  • формате ключей (CryptoKey вместо Buffer)
  • ограничениях на алгоритмы

Ограничения на бинарные данные

Edge Runtime работает в первую очередь с:

  • Uint8Array
  • ArrayBuffer
  • string (UTF-8)

Node.js-специфичный Buffer может отсутствовать или быть частично эмулирован, что создаёт несовместимости при работе с криптографией и сериализацией.


Iron-session и Edge Runtime

Библиотеки семейства Iron (например, iron-session) используются для безопасного хранения данных в cookie через:

  • сериализацию session-объекта
  • шифрование
  • подпись данных
  • защиту от подделки

В Node.js это реализуется через crypto и синхронные операции, но в Edge среде возникают ограничения.


Ключевые проблемы совместимости

1. Зависимость от Node crypto API

Если библиотека использует:

  • crypto.createHmac
  • crypto.randomBytes
  • crypto.createCipher

то в Edge Runtime это не будет работать напрямую.

Вместо этого требуется:

  • crypto.subtle.sign
  • crypto.subtle.encrypt
  • crypto.getRandomValues

2. Синхронная модель шифрования

Node.js допускает синхронные криптооперации, что упрощает API.

Edge Runtime требует:

  • полностью асинхронных операций
  • await на каждом этапе криптографии

Это влияет на архитектуру session-менеджмента: логика становится цепочкой промисов, а не последовательным кодом.


Edge Runtime часто используется в связке с CDN и прокси, где действуют ограничения:

  • ~4 KB на cookie (стандарт браузеров)
  • дополнительные ограничения платформы

Это критично для Iron-сессий, так как:

  • всё состояние хранится в cookie
  • увеличение payload напрямую влияет на latency и лимиты

Как Iron-подход адаптируется под Edge

Использование Web Crypto API

В Edge-среде шифрование должно быть переписано под:

  • crypto.subtle.encrypt
  • crypto.subtle.decrypt
  • crypto.subtle.importKey
  • crypto.subtle.exportKey

Пример концептуального различия:

Node.js (упрощённо):

crypto.createCipher('aes-256-gcm', key)

Edge Runtime:

await crypto.subtle.encrypt(
  { name: "AES-GCM", iv },
  cryptoKey,
  data
)

Иммутабельность и сериализация

Edge Runtime работает эффективнее с:

  • чистыми объектами
  • JSON-сериализацией
  • отсутствием классов и прототипных цепочек

Поэтому session-объекты Iron-подхода должны быть:

  • плоскими структурами
  • без методов
  • без вложенных нестандартизированных типов

Stateless-first архитектура

Edge окружение стимулирует:

  • отсутствие серверного состояния
  • хранение всего в cookie или external KV (Redis, Edge KV)

Iron-сессии идеально вписываются в модель:

  • данные → сериализация → шифрование → cookie
  • запрос → расшифровка → восстановление состояния

Типичные ошибки при переносе Iron на Edge Runtime

Использование Node Buffer

Многие реализации ломаются из-за:

  • Buffer.from
  • Buffer.concat

В Edge требуется замена на:

  • Uint8Array
  • TextEncoder / TextDecoder

Случайное использование Node-only библиотек

Часто встречаются зависимости:

  • uuid (старые версии)
  • bcrypt
  • jsonwebtoken (без edge-версии)

Все они могут использовать недоступные API.


Несовместимость с middleware-архитектурой

Edge Runtime часто используется в:

  • Next.js Middleware
  • Route Handlers (edge mode)

Важно учитывать:

  • нет доступа к серверному runtime
  • нет persistent memory между запросами
  • нельзя использовать долгие вычисления

Производительность Iron-сессий в Edge

Edge Runtime даёт преимущества:

  • минимальная задержка (ближайший POP)
  • отсутствие cold start (или минимальный)
  • высокая масштабируемость

Но накладывает ограничения:

  • криптография может быть медленнее, чем native Node bindings
  • сериализация становится узким местом
  • размер cookie критичен для latency

Оптимизационные подходы

Минимизация payload

Рекомендуется:

  • хранить только идентификаторы
  • избегать вложенных структур
  • не хранить массивы без необходимости

Кэширование ключей

В Edge можно кэшировать:

  • CryptoKey после importKey

Это уменьшает overhead на каждом запросе.


Использование lazy decryption

Данные можно расшифровывать:

  • только при доступе к session
  • а не на этапе middleware

Архитектурный паттерн Edge + Iron

Типичная схема выглядит так:

  1. Запрос приходит в Edge Function
  2. Cookie извлекается из headers
  3. Web Crypto расшифровывает session
  4. Бизнес-логика работает с plain object
  5. При завершении session сериализуется
  6. Данные шифруются и записываются обратно в cookie

Границы применимости Iron в Edge Runtime

Edge Runtime подходит для Iron-подхода, если:

  • данные сессии небольшие
  • нет сложной серверной логики
  • нет необходимости в файловой системе
  • криптография реализована через Web Crypto API

Не подходит, если:

  • требуется heavy computation
  • нужны Node-native крипто-библиотеки
  • требуется доступ к внешним процессам или бинарным модулям