<b>Edge compute ломается не на коде, а на скрытом state и лишнем I/O</b>

<b>Edge compute ломается не на коде, а на скрытом state и лишнем I/O</b>

Edge-функция должна жить коротко: получил запрос, сделал минимум работы, вернул ответ. Если тянуть в неё тяжёлый SDK, ходить по нескольким API или собирать данные по цепочке, выигрыша от edge_compute почти не остаётся.

Проверь архитектуру на 4 вещи:
— всё, что можно отдать как static или через isr, не тащи в ssr;
— любые записи в БД и сложные транзакции выноси из edge;
— в edge оставляй только auth, routing, A/B, geo и лёгкую персонализацию;
— не храни там состояние между запросами: кэш и глобальные переменные ведут себя не так, как ждут команды.

Отдельно следи за размером бандла и количеством сетевых прыжков. На edge дорог не сам JavaScript, а время до первого полезного байта: каждый лишний fetch, парсинг и повторная сериализация съедают смысл переноса ближе к пользователю.

Если функция не укладывается в «один запрос — одна короткая операция», лучше перестроить её в гибрид: edge для маршрутизации, serverless или обычный ssr для тяжёлой логики. Именно так nextjs и vercel дают предсказуемый результат без магии.