Cloudflare Workers для новичка: публикуем JavaScript API без своего сервера

Cloudflare Worker принимает Request и возвращает Response по публичному URL без настройки собственного VPS. Соберём маленький API заметок, запустим его через Wrangler, проверим GET и POST, затем разберём ограничения serverless-среды. Код использует стандартные Web API и не хранит данные между запросами.

Фраза «без сервера» скрывает платформу, деплой и ограничения runtime. Worker всё равно выполняется на серверной инфраструктуре, просто операционную систему обслуживает провайдер. В этой статье вы соберёте публичный JSON endpoint с двумя методами. Финальный результат можно проверить без догадок: wrangler dev отвечает локально, deploy выдаёт HTTPS URL, а неверный JSON возвращает 400 вместо падения.

Как запрос попадает в Cloudflare Worker

В модульном формате default export содержит async fetch. URL помогает выбрать путь, request.method разделяет GET и POST, а Response.json сериализует тело. Процесс не слушает порт и не вызывает app.listen. Для Cloudflare Workers держите этапы раздельно: ввод, проверка, основное действие и вывод. Такой маршрут позволяет остановиться в конкретной точке, увидеть фактические данные и исправить одну причину вместо случайной перестановки строк.

Один handler работает локально и на платформе, но только в рамках поддерживаемых Web API. У Cloudflare Workers каждый этап оставляет наблюдаемый след, поэтому следующий шаг начинается только после проверки предыдущего.

От входных данных до видимого результата. Wrangler повторяет платформенный runtime

Пишем JavaScript API заметок

Установите актуальный Node.js и выполните npm create cloudflare@latest -- notes-worker. В мастере выберите Hello World example, Worker only и JavaScript, а первый deploy отложите. Перейдите в каталог и запустите npm run dev. Официальный CLI создаёт wrangler.jsonc и src/index.js. Авторизация потребуется только перед реальной публикацией.

const json = (data, status = 200) =>
  Response.json(data, {
    status,
    headers: { "cache-control": "no-store" },
  });

export default {
  async fetch(request) {
    const url = new URL(request.url);

    if (url.pathname !== "/api/note") {
      return json({ error: "route not found" }, 404);
    }

    if (request.method === "GET") {
      return json({ text: "Learn one Web API today" });
    }

    if (request.method === "POST") {
      let body;
      try {
        body = await request.json();
      } catch {
        return json({ error: "invalid JSON" }, 400);
      }

      if (typeof body.text !== "string" || !body.text.trim()) {
        return json({ error: "text is required" }, 400);
      }
      return json({ text: body.text.trim() }, 201);
    }

    return json({ error: "method not allowed" }, 405);
  },
};

Вспомогательная json-функция удерживает одинаковые заголовки и форму ответа, а handler остаётся читаемым. Пример Cloudflare Workers специально ограничен одним пользовательским сценарием, чтобы назначение каждой строки оставалось видимым.

Что отличает устойчивый проект от случайного запуска. Без VPS не означает без инфраструктуры

Чем Worker отличается от Node.js сервера

Workers runtime построен на V8 и реализует многие Web Platform APIs. Request, Response, URL и fetch знакомы по браузеру. Node.js модули и файловая система доступны не так, как на обычном сервере, поэтому библиотеку нужно проверять на совместимость. Handler может выполняться рядом с пользователем, однако данные и внешние запросы имеют собственную географию. wrangler dev моделирует среду лучше, чем прямой node src/index.js.

Worker не гарантирует долгоживущий процесс. Инициализация модуля может переиспользоваться для нескольких запросов, но полагаться на это для данных нельзя. CPU time и лимиты зависят от тарифа и актуальных правил платформы. Для CORS добавляйте заголовки только под нужный origin и обрабатывайте OPTIONS. Секреты задаются через Wrangler secrets, а не wrangler.jsonc. Cache API полезен для идемпотентных GET, но POST-ответы обычно не кешируют.

Проверяем методы, JSON и деплой

Запустите npm run dev и проверьте GET. Отправьте POST с корректным JSON, затем с пустой строкой и сломанным телом. Добавьте query-параметр uppercase=1, который меняет только представление GET. Напишите маленький test через Vitest или встроенный шаблон Workers. После локального успеха выполните npx wrangler deploy, сохраните URL и повторите четыре запроса. Затем удалите учебный Worker, если он больше не нужен.

Serverless упрощает сервер, но не отменяет контракт API, хранение данных и безопасность публичного адреса. После этой проверки измените одно правило Cloudflare Workers и заранее запишите ожидаемый результат. Так копирование превращается в понимание.

Четыре проверки перед следующим шагом. Публичный endpoint требует границ

Что учесть перед настоящим serverless API

Для постоянных заметок выберите хранилище по задаче и напишите миграцию данных. Добавьте аутентификацию до write-route, CORS для конкретного фронтенда и rate limit. Логи не должны содержать токены или полные персональные данные. Закрепляйте compatibility_date и обновляйте её после тестов, потому что runtime развивается. Для локального теста используйте Wrangler, а не предполагайте, что любой Node-пакет заработает на edge.

Как изучить тему в Кодике

Закрепите fetch, Request, Response, async/await и JSON в JavaScript, затем добавьте деплой как отдельный шаг. В Кодике сначала восстановите чистую логику без фреймворка, затем верните библиотеку и интерфейс Cloudflare Workers.

Если handler можно проверить обычным набором Request, платформа перестаёт быть чёрным ящиком. Финальная проверка для Cloudflare Workers: закрыть статью, объяснить путь данных и добавить одну функцию без копирования готового блока.

Что получится в итоге

Один Worker обрабатывает GET и POST, возвращает ясные статусы и публикуется по HTTPS без ручной настройки VPS.