Наш опыт добавления Edge Runtime в Next.js SDK

Интродукция#

Edge Runtime стало популярным в технологической сфере, обеспечивая динамическую, низкую задержку в различных платформах от AWS Lambda@Edge и Cloudflare Workers до Vercel Edge. Подчеркивая его важность, Vercel недавно изменил "experimental-edge" на просто "edge", сигнализируя официальную поддержку в их популярном фреймворке Next.js.

На Next.js SDK у нас серьезное следование, поэтому в Logto мы думали: "Почему бы не добавить поддержку Edge Runtime?" Поэтому мы перекатили рукава и просто в него прыгнули. В этой статье мы собираемся поделиться нашим приключением, рассмотреть препятствия, с которыми мы столкнулись, как мы их преодолели, и крутые вещи, которые мы узнали по дороге.

Переход модулей и зависимостей для поддержки Edge Runtime#

Работа с Edge Runtime представляет собой некоторые уникальные вызовы, главным образом, потому что она не поддерживает все модули и зависимости, обычно используемые в Node.js. Мы столкнулись с этой проблемой с модулями crypto, lodash и iron-sessions, что потребовало некоторых инновационных обходных путей.

Crypto#

В окружающей среде Node.js модуль crypto служит оболочкой для криптографических функций OpenSSL. К сожалению, Edge Runtime не поддерживает его. Но не волнуйтесь - большинство сред прогонки Edge спасают поддерживая Web Crypto API. Несмотря на некоторые незначительные различия, это надежная замена для модуля crypto. Например, для генерации случайных байтов:

И хеширование:

Lodash#

Lodash является фаворитом среди многих разработчиков за его утилитарность, но Edge Runtime не является его фанатом. Наш обходной путь? Мы заменили функции Lodash на встроенные методы JavaScript, делая наш код эффективным и читаемым.

Хоть замена большинства функций Lodash и не была задачей Геракла, но она требовала некоторого внимания. Давайте посмотрим, как мы воссоздали утилиту "once" своим способом:

Iron Session#

Последняя версия модуля iron-session дружественна к Edge Runtime, так что все, что нам нужно было сделать, это обновить нашу версию. Так просто!

Ориентирование в тонкостях "Response" в Edge Runtime#

Другой вызов, с которым мы столкнулись при адаптации нашего SDK для Edge Runtime, связан с разницей в объекте "Response". Вот как мы преодолели эти различия:

Создание ответа вручную#

В отличие от Node.js, запрос в Edge Runtime не поставляется с подготовленным ответом. Это означает, что нам нужно создать его самостоятельно, вызвав new Response(), вот пример возвращения данных:

Отказ от "withIronSessionApiRoute"#

В Edge Runtime Response.body является доступным только для чтения. Это означает, что мы не смогли инициализировать ответ, прежде чем данные были подготовлены. В результате, нам пришлось отказаться от нашего доверенного "withIronSessionApiRoute" (вместе с другим промежуточным ПО).

Чтобы понять, что мы заменили, давайте сначала разберем, что же на самом деле делает withIronSessionApiRoute:

1. Он заглядывает в cookie, конструирует объект сессии и связывает его с res.
2. Он автоматически добавляет заголовок "set-cookie" к res, если произошло изменение сессии.

Так как же мы воспроизводили эту функциональность в нашем новом окружении Edge Runtime?

1. Чтение: Мы использовали существующую функцию getIronSession. Давая ему пустой и фиктивный response, мы получали сессию по мере необходимости. Это заменило метод "get" из req.session.
2. Запись: Мы заранее подготовили response с данными, затем использовали getIronSession с этим экземпляром response, чтобы получить объект сессии. Получив этот объект, мы могли изменить сессию по мере необходимости.

Перенаправление#

Перенаправление в Edge Runtime требовало от нас ручного добавления заголовка Location в наши ответы.

Один пакет, два среды выполнения#

В этом нашем путешествии мы решили придерживаться одного пакета для поддержки обоих сред выполнения - Edge и Node.js.

Вот почему#

Мы подумали о создании отдельного пакета для Edge, но быстро поняли, что это необязательно. Большинство нашего кода было общим для обоих сред выполнения, только несколько строк требовали корректировки. Кроме того, использование SDK остается почти одинаковым в обоих средах выполнения, поэтому поддержание единого пакета было наиболее разумным.

Вот что мы сделали#

Вместо дублирования усилий, мы решили расширить существующий пакет. Мы добавили папку "edge" прямо в корень пакета, рядом со старой папкой "src". Затем мы обновили файл package.json, добавив новый путь в "exports". Таким образом, могут сосуществовать обе среды выполнения - Edge и Node.js - внутри одного пакета, без лишних хлопот.

Заключение#

Вы можете проверить полный исходный код нашей части SDK Next.js edge здесь.

Делясь нашим путешествием включения Edge Runtime, мы надеемся вдохновить и направить других, исследующих похожие пути. Следите за новостями об обновлениях нашего SDK Next.js.