Cloudflare Workers против кода на origin для простых правил на edge

Почему этот выбор быстро усложняется

Сравнение Cloudflare Workers с кодом на origin становится запутанным раньше, чем ожидает большинство команд. Запрос больше не идёт по одному пути. Он может сначала попасть на edge, там измениться, а затем дойти до приложения, где снова сработает другой набор правил.

Это звучит нормально, если edge-правило совсем маленькое. Возможно, вам нужен только редирект, проверка бота или быстрый взгляд на session cookie. Но теперь у одного запроса есть два места, где принимаются решения, и оба могут менять то, что будет дальше.

Чаще всего первым ломается работа с URL. Worker может переписать /login в /app/login или перенаправить example.com на www, а origin при этом продолжит применять собственную правку со слэшем в конце, редирект по локали или старое правило маршрутизации. Теперь два уровня трогают один и тот же URL, и они не всегда согласны друг с другом.

Когда это происходит, баги выглядят случайными. Один пользователь получает 301, другой — 302, а кто-то ещё попадает в цикл редиректов из-за того, что на edge изменился заголовок. Кэш только усугубляет ситуацию. Плохой редирект может закрепиться надолго, и вы начнёте винить приложение, хотя с ним всё в порядке.

Auth-проверки расходятся так же быстро. Всё начинается с простого правила: если cookie есть, пропускаем запрос дальше. Потом добавляются разбор токена, проверка ролей, исключения по путям, редиректы на login, логика обновления и особая обработка API-запросов. В этот момент edge уже делает не маленькую проверку. Он выполняет часть работы приложения.

Такое разделение съедает время каждый раз, когда что-то ломается. Вы смотрите логи Worker, потом логи приложения, потом заголовки запроса, потом закэшированные ответы. Один и тот же запрос приходится воспроизводить дважды, потому что первая версия даже не дошла до origin. Баг, который должен был занять 10 минут, растягивается на час просто потому, что правило живёт в двух местах.

Самая сложная часть — не лишний код. А неопределённость. Когда запрос падает, команда перестаёт понимать, где находится истина. Даже небольшие изменения начинают казаться рискованными.

Что лучше держать ближе к edge

Edge лучше всего подходит для решений, которые занимают несколько миллисекунд и используют только сам запрос перед вами. Если правило может работать без обращения к базе, без состояния приложения и без другого сервиса, ему обычно место там.

Простые редиректы — самый очевидный выигрыш. Если запрос пришёл на старый host, устаревший путь или обычную HTTP-точку входа, edge может вернуть редирект ещё до того, как приложение начнёт что-то делать. Это снижает нагрузку на origin и не тратит время на запросы, которые вы и так уже умеете маршрутизировать.

Очевидный bot-трафик тоже хорошо отсеивать на edge. Если у запроса сломанный user agent, он приходит из страны, которую вы уже блокируете, или совпадает с мусорным трафиком, который вы видите каждый день, останавливайте его рано. Ваше приложение не должно тратить CPU на шум.

Там же может жить и маленькая проверка allow/deny. Например, cookie, которая показывает наличие signed-in session, или header, который помечает запрос от внутреннего инструмента. Edge может ответить на простой вопрос: продолжать или отправить пользователя на login. Держите это узко. Проверка наличия подходит. Полная логика прав доступа — нет.

Очистка заголовков — ещё один хороший вариант. Edge может нормализовать host headers, добавить cache-hints, убрать недоверенные заголовки или поставить один простой заголовок, который сообщит origin то, что он уже узнал.

Полезное правило здесь нарочно скучное:

• Правило использует только path, host, method, headers, cookies или IP-данные, уже присутствующие в запросе.
• Правило выполняется быстро и не нуждается в общем состоянии.
• Правило легко объяснить одним предложением.
• Если оно ломается, исправление очевидно.

Последний пункт особенно важен. В споре Cloudflare Workers vs origin code edge должен оставаться скучным. Как только Worker начинает вызывать API, читать сложные данные сессии или принимать разветвлённые решения, которые повторяют логику приложения, вы строите второе приложение перед первым.

Достаточно простого примера: перенаправить /old-pricing на /pricing, заблокировать мусорные bot-паттерны и проверить, есть ли cookie auth, прежде чем пускать кого-то на /admin. Такие действия остаются быстрыми, локальными и удобными для отладки.

Что должно оставаться на origin

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

В споре Cloudflare Workers vs origin code деньги и права доступа обычно должны оставаться на origin. Ваше приложение уже знает тариф пользователя, статус trial, лимиты по местам, флаги аккаунта и прошлые действия. Дублирование этой логики в Worker сначала выглядит быстрым, а потом превращается в два источника истины.

Разделение простое. Worker может проверить, есть ли у запроса session cookie, и отправить анонимных пользователей на login. Но если нужно понять, может ли этот пользователь открыть админ-раздел, скачать платный отчёт или выйти за лимит использования, решать должен origin. Такие проверки зависят от полных пользовательских записей, а не только от заголовков и токена.

Billing тоже относится туда. Если запрос может запустить платное действие, списать credits, посчитать платное использование или открыть функцию, пусть этим займётся приложение, которому принадлежат данные. Один billing-баг на edge может быстро нанести реальный ущерб.

То же самое касается audit logs. Когда пользователь меняет пароль, экспортирует данные, принимает договор или открывает чувствительную страницу, записывайте audit-событие рядом с кодом приложения, который принял решение. Так действие, причина и сохранённая запись остаются в одном месте.

Держите на origin проверки прав, которые читают данные аккаунта, решения по pricing и billing, audit-логи для чувствительных действий, многошаговые сценарии вроде checkout или восстановления аккаунта, а также побочные эффекты вроде писем или создания invoice. Редиректы, bot-проверки и маленькие auth-шаги хорошо подходят для edge. Состоящая из состояния работа — нет.

Используйте одно правило для разделения работы

Большинство команд застревают в споре Cloudflare Workers vs origin code, потому что сначала делят по технологии. Лучшее разделение — по риску.

Если правило быстрое, очевидное и дешёвое в случае ошибки, отправляйте его на edge. Если оно зависит от session state, billing, прав доступа или чего-то, что может помешать реальному пользователю делать бизнес, оставляйте его на origin.

Обычно это означает, что edge обрабатывает небольшие проверки с понятным результатом. Редирект со старого пути на новый хорошо подходит. Как и отклонение запроса с плохим bot score или отказ при отсутствии заголовка до того, как он потратит время приложения. Такие правила короткие, повторяемые и почти одинаковые для каждого запроса.

Origin должен владеть всем, у чего есть память или деньги. Login-state, лимиты аккаунта, доступ по тарифу, логика coupon и правила checkout должны жить в приложении. Если ошибка может закрыть человеку доступ, утечь данные или списать деньги не с того человека, Worker не должен принимать окончательное решение.

Назначайте одному маршруту одного понятного владельца. Если /login принадлежит приложению, пусть Worker делает только тонкую защиту перед ним, например rate limiting или базовый блок по стране. Само приложение всё равно решает, может ли пользователь войти. Если /checkout живёт на origin, не разбивайте путь принятия решения и не переносите половину проверок в edge-код.

Сначала пишите полное правило в приложении, даже если кажется, что позже его можно перенести. Так у вас будет одно место для тестов, логов и отладки. После этого добавьте тонкую edge-защиту только если она реально экономит работу, например отсекает очевидный мусорный трафик или обрабатывает редирект, которому не нужны данные приложения.

Быстрая проверка помогает. Если правилу нужна session, база данных или свежие данные аккаунта, оставьте его на origin. Если ошибка может стоить денег или заблокировать платящего пользователя, оставьте его там же. Если один и тот же ответ подходит почти всем и версия на edge убирает достаточно шума, чтобы это имело смысл, edge, скорее всего, подходит.

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

Как принимать решение шаг за шагом

Большинство команд усложняют это больше, чем нужно. Написать редирект или bot-фильтр — не самая трудная часть. Труднее сохранить правило понятным, дешёвым в работе и очевидным для изменений через шесть месяцев.

Начните с простого списка. Запишите все редиректы, проверки ботов и маленькие auth-шаги, которые уже используете или планируете добавить. Используйте реальные правила, а не расплывчатые названия. «Redirect /old-pricing to /pricing» — полезно. «Обрабатывать старые URL» — нет.

Потом отсортируйте каждое правило с помощью нескольких базовых проверок. Сначала спросите, нужны ли ему данные из приложения, например обращение к базе, запись пользователя, feature flag или состояние сессии. Если да, оставляйте его на origin, если только у вас нет очень веской причины этого не делать.

Затем посмотрите, как часто правило меняется. Маркетинговые редиректы, которые не меняются месяцами, хорошо подходят для edge. Login-логика, которая меняется вместе с продуктом, обычно — нет.

После этого оцените цену ошибки. Неправильный редирект по стране раздражает. Неправильное решение по auth может закрыть пользователям доступ или, наоборот, впустить их. Высокорисковые проверки должны жить ближе к коду и логам, которым ваша команда уже доверяет.

Переносите на edge только дешёвые и стабильные правила. Фиксированные редиректы, простая фильтрация ботов, нормализация заголовков и маленькие предварительные проверки вроде «есть ли у этого запроса вообще token?» — хорошие кандидаты.

И наконец, дайте каждому правилу владельца, лог и путь отката. Кто-то должен знать, где живёт правило, что именно оно сделало и что произойдёт, если Worker сломается или его обойдут.

Небольшой пример делает разделение очевидным. Если вы хотите блокировать очевидный scraping, перенаправлять старые campaign-URL и защищать /dashboard, редирект и первичную bot-проверку можно выполнять на edge, потому что они быстрые и в основном статичны. Но реальная проверка прав на dashboard должна оставаться на origin, потому что она зависит от живого состояния пользователя.

Если правило начинается просто, но всё время разрастается, заберите его обратно. Обычно это и есть сигнал. Как только Worker начинает нуждаться в общих константах, специфических исключениях приложения и мышлении в стиле базы данных, вы уже не формируете запросы. Вы строите второе приложение.

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

Реальный пример с редиректами и login-проверками

Представьте посетителя, который нажимает старую campaign-ссылку из письма, отправленного три месяца назад. Он открывает /promo/spring, но этой страницы больше нет. Worker может перехватить этот запрос на edge и отправить один чистый редирект на текущую landing page ещё до того, как запрос коснётся вашего app-сервера.

Это хороший случай для edge, потому что правило простое и стабильное. Worker не нуждается в product-данных, истории аккаунта или чтении базы. Он просто сопоставляет старый путь с новым и быстро возвращает ответ.

Теперь добавим базовую фильтрацию трафика. Если запрос совпадает с очевидным bot-паттерном, Worker может остановить его рано. Это может быть плохой user agent, всплеск повторяющихся обращений или шаблон запроса, который обычный браузер никогда бы не отправил. Вы сохраняете мощность origin для реальных пользователей, а не тратите её на мусор.

Тот же поток запроса может содержать небольшую auth-проверку для /app. Когда кто-то запрашивает этот путь, Worker ищет подписанную cookie. Если cookie нет, она просрочена или не проходит проверку подписи, Worker сразу перенаправляет посетителя на страницу login.

Эта проверка должна оставаться узкой. Worker не должен решать, что именно человек может видеть внутри продукта. Он должен отвечать только на один маленький вопрос: похож ли этот запрос на запрос от вошедшего пользователя?

Если cookie проходит проверку, Worker передаёт запрос на origin. Затем origin делает более тяжёлую работу. Он загружает запись пользователя, проверяет тариф, читает membership в команде и решает, может ли человек открыть billing, редактировать проект или приглашать коллег.

Такое разделение сохраняет поток чистым. Edge даёт быстрые ответы почти без контекста. Origin занимается бизнес-правилами.

В лучшем смысле эта схема ощущается скучной. Редиректы остаются быстрыми, очевидные боты останавливаются рано, а login-барьер работает близко к пользователю. При этом app-сервер по-прежнему владеет настоящими решениями, так что product-логика не расползается по двум местам.

Ошибки, которые создают два приложения

Путаница обычно начинается с короткого пути. Команда копирует allow list в Worker для быстрого блокирования, а потом оставляет тот же список в приложении, потому что «приложению он всё равно нужен». Через две недели один список меняется, а другой — нет. Теперь edge говорит yes, приложение говорит no, и никто не доверяет обоим ответам.

Такое расхождение усиливается, когда команды переносят проверки ролей в edge-слой. Worker может видеть cookie, token или header. Но он обычно не видит полное состояние пользователя, которое знает приложение, например заблокированные аккаунты, membership в команде, лимиты тарифа или ручное исключение от support. Если Worker решает, кто считается admin, и приложение тоже решает это, у вас теперь две auth-системы с разными фактами.

Частая ловушка выглядит безобидно: Worker пускает пользователей в /reports, если claim в токене говорит role=manager, но приложение блокирует их, потому что утром у них истёк subscription. Пользователи называют это случайным багом. Но он не случайный. Правило живёт в двух местах.

Вызовы внешних сервисов до того, как запрос увидит приложение, создают ту же проблему. API для bot score, проверка feature flag или удалённый allow list добавляют задержку и ещё одну точку отказа до того, как начнёт работать ваш собственный код. Когда такой сервис начинает тайм-аутиться, команды начинают добавлять bypass. Эти обходы быстро накапливаются.

Расхождение начинается с малого

Общие request ID очень помогают. Если Worker блокирует или переписывает запрос, он должен прикрепить один request ID и передать его на origin. Приложение должно логировать тот же ID. Без этой нити вы в итоге смотрите на логи Cloudflare и приложения, которые никогда не совпадают.

Признаки довольно очевидны:

• Одно и то же правило пути существует и в Worker-коде, и в коде приложения.
• Edge принимает решения по ролям или тарифам.
• Worker вызывает сторонние сервисы в цепочке запроса.
• Логи edge и приложения не используют один request ID.
• Исключений для партнёров, старых клиентов или разовых кампаний становится всё больше.

Именно тогда Cloudflare Workers vs origin code перестаёт быть чистым разделением и превращается в два приложения, которые притворяются одним. Оставьте редиректы на edge, отсекайте там очевидный мусор и делайте только маленькие проверки, которые зависят от фактов самого запроса. Пусть origin владеет состоянием пользователя, billing, ролями и бизнес-правилами.

Быстрые проверки перед запуском

Большинство споров Cloudflare Workers vs origin code становятся проще, если перед запуском правила задать несколько простых вопросов. Если правило не проходит эту проверку, верните его на origin или перепишите так, чтобы оно стало скучным.

Хорошее edge-правило достаточно маленькое, чтобы новый участник команды смог объяснить его примерно за минуту. Если ему нужна доска, три оговорки и схема cookies, правило слишком большое для edge.

Используйте короткий чек-лист:

• Не переносите на edge правила, которым нужен database read на каждом запросе.
• Попросите кого-то ещё объяснить правило вслух.
• Дайте Worker и origin один и тот же request ID и логируйте его в обоих местах.
• Убедитесь, что origin всё ещё сможет обработать запрос, если Worker сломается, истечёт по тайм-ауту или будет откатан.
• Назначьте одного владельца рядом с каждым правилом.

Небольшой пример делает это реальным. Допустим, вы делаете редиректы на edge для старых campaign-URL и выполняете лёгкую auth-проверку для admin-раздела, просто проверяя подписанную cookie. Это может работать хорошо. Worker может перенаправить /spring-sale на текущую страницу и отбрасывать очевидных плохих ботов ещё до приложения. Но origin всё равно должен уметь отдать конечную страницу и правильно проверить session.

Именно последняя часть важна. Если Worker проверяет только наличие cookie, а приложение считает cookie валидной по умолчанию, вы создаёте дыру. Если Worker упадёт, а origin не сможет продолжить, вы создаёте простой.

Записывайте эти проверки в задачу на rule или в комментарий к конфигу. Через шесть месяцев эта короткая заметка будет важнее самого кода.

Следующие шаги для более чистой схемы

Чистая схема обычно начинается с малого. Возьмите одну группу редиректов или одно bot-правило и перенесите только его на edge. Остальное пока не трогайте, чтобы можно было измерить результат, не превращая путь запроса в игру в угадайку.

Большинство команд попадают в неприятности, когда переносят сразу пять маленьких проверок, а потом теряют из виду, какой уровень принял решение. Маленький первый шаг помогает не превратить спор Cloudflare Workers vs origin code в два отдельных приложения с перекрывающимися правилами.

Держите запуск простым:

• Выберите одно правило с понятным результатом yes/no.
• Определите, какие данные edge может читать, а какие он должен игнорировать.
• Отметьте, что по-прежнему должно оставаться на origin.
• Логируйте каждое решение нового правила.
• Назначьте дату для пересмотра результатов.

Потом наблюдайте за логами всю неделю. Ищите ложные блокировки ботов, redirect-циклы, лишние login-барьеры и запросы, которым всё ещё нужны данные origin. Если растёт число обращений в поддержку или логи выглядят грязно, остановитесь и исправьте правило, прежде чем переносить ещё одну проверку.

Запишите границу простыми словами и держите её там, где команда действительно будет это читать. Одного предложения часто достаточно: «Edge может перенаправлять, блокировать очевидный мусор и проверять простой token. Origin решает права доступа, pricing, состояние аккаунта и все бизнес-правила».

Эта фраза экономит время на code review. Она также помогает новым инженерам не добавлять в Worker ещё одно «ну это же всего одно правило», потому что сегодня так удобнее.

Если разделение всё ещё кажется размытым, второе мнение может сэкономить много уборки позже. Oleg Sotnikov на oleg.is работает как Fractional CTO и startup advisor, и именно такие границы между edge-правилами, логикой приложения и инфраструктурой проще исправить заранее, чем после месяцев расхождения.

Чистая схема обычно самая скучная. Edge обрабатывает быстрые и очевидные проверки. Origin — всё, что требует контекста.