Backend еще не готов? Как не остановить фронтенд и быстро поднять тестовое API

Кажется, раньше у многих был стандартный сценарий: делаешь фронтенд, backend еще не готов, и ты начинаешь искать бесплатный API.

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

Но сейчас появился еще один вариант: просто спросить AI.

Написать в ChatGPT, Codex или любой другой инструмент что-то вроде:

Сделай мне простое API на Express с пользователями

И он действительно выдаст рабочий код.

Тут как будто возникает вопрос: а зачем тогда вообще читать статью?

И вот здесь важный момент.

Проблема обычно не в том, чтобы получить 30 строк JavaScript. Это AI сейчас делает довольно неплохо. Проблема в другом: понять, какие данные нужны интерфейсу, какие состояния надо проверить и где заканчивается тестовое API, а начинается нормальная backend-разработка.

Потому что фронтенд редко ломается на счастливом сценарии, где сервер сразу вернул красивый список пользователей.

Он ломается, когда:

• данных нет;
• запрос идет слишком долго;
• сервер вернул 400;
• пользователь не найден;
• форма отправилась два раза;
• CORS решил напомнить о себе;
• структура ответа не совпала с тем, что ожидает UI.

Вот об этом и поговорим.

Не просто "как написать API на Express", а как быстро сделать себе рабочий инструмент, чтобы не ждать backend и нормально проверять фронтенд.

Когда вообще нужен свой тестовый API

Я бы смотрел на это не как на "давайте напишем backend", а как на способ не остановить разработку.

Свой временный API полезен, если:

• backend еще не готов, а интерфейс уже нужно собирать;
• ты делаешь pet-проект и хочешь показать его живым, а не на моках в компоненте;
• нужно проверить формы, ошибки, загрузку и пустые состояния;
• нужно показать демо клиенту или команде;
• бесплатный API почти подходит, но структура данных постоянно мешает;
• хочется заранее договориться, как примерно будут выглядеть будущие endpoints.

Например, ты делаешь CRM. В интерфейсе есть клиенты, сделки, статусы, менеджеры, фильтры и карточка клиента. Бесплатный API с постами и пользователями тут может помочь только на самом старте. Дальше все равно придется подгонять данные под продукт.

А если ты сам делаешь тестовое API, то можешь сразу вернуть такие поля, которые реально нужны интерфейсу:

{
  id: 1,
  name: 'Алиса',
  email: 'alice@mail.ru',
  role: 'designer',
  status: 'active'
}

И фронтенд начинает работать с нормальной структурой, а не с чужим форматом, который ты потом героически преобразуешь на клиенте.

Почему не всегда достаточно AI

AI отлично помогает быстро сгенерировать основу.

Но он не всегда знает контекст твоего проекта:

• какие поля реально есть в макете;
• какие состояния должен показывать интерфейс;
• как backend будет устроен потом;
• какие ошибки важно протестировать;
• какие ограничения есть у команды;
• что нужно показать клиенту уже завтра.

Поэтому я бы использовал AI как ускоритель, а не как замену мышления.

Можно попросить его сгенерировать код, но перед этим самому ответить на несколько вопросов:

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

Вот тогда AI становится реально полезным. Он пишет быстрее, а ты понимаешь, что именно он должен написать.

Какие есть варианты, если backend еще не готов

Обычно вариантов несколько.

Можно взять бесплатный публичный API. Это быстро, особенно если нужно просто вывести карточки или список. Минус в том, что структура данных чужая, лимиты тоже чужие, и надежность не всегда под твоим контролем.

Можно использовать json-server. Это крутой вариант, когда хочется почти моментально получить REST API из одного JSON-файла. Очень удобно для прототипов.

Можно генерировать данные через Faker. Например, пользователей, emails, адреса, товары, компании. Это помогает, когда нужно много похожих тестовых данных.

Можно взять Strapi, если уже нужна админка, коллекции, роли и управление контентом. Я отдельно разбирал создание проекта на Strapi - для MVP и контентных проектов это часто прям хороший путь.

А можно написать маленький Express-сервер.

И вот Express удобен, когда хочется контролировать не только данные, но и поведение API: статусы, задержки, ошибки, разные сценарии.

Что мы будем делать

Давайте соберем простой тестовый API на Express.

Без базы данных, Docker, авторизации и сложной архитектуры.

Нам понадобится:

• Node.js LTS;
• Express;
• пакет cors, если фронтенд и API работают на разных портах;
• обычный массив с данными;
• 10-15 минут времени.

Наша цель - не сделать production backend. Наша цель - получить инструмент, который поможет фронтенду двигаться дальше.

Быстро поднимаем проект

Проверяем, что Node.js и npm установлены:

node -v
npm -v

Создаем папку:

mkdir test-api
cd test-api
npm init -y

Ставим Express и CORS:

npm install express cors

В package.json добавим scripts:

{
  "scripts": {
    "start": "node index.js",
    "dev": "node --watch index.js"
  }
}

node --watch удобен тем, что сервер сам перезапускается после изменений. Не главная магия в мире, но в работе приятно.

Пишем основу сервера

Создаем файл index.js:

const express = require('express')
const cors = require('cors')

const app = express()
const PORT = 3000

app.use(cors())
app.use(express.json())

Что здесь происходит:

• express() создает приложение;
• cors() помогает фронтенду обращаться к API с другого origin, например с localhost:5173;
• express.json() позволяет серверу читать JSON из тела запроса.

Для локального тестового API можно включить CORS широко через app.use(cors()). Для production так лучше не делать бездумно, но сейчас мы решаем задачу разработки.

Добавим данные:

let users = [
  {
    id: 1,
    name: 'Алиса',
    email: 'alice@mail.ru',
    role: 'designer',
    status: 'active'
  },
  {
    id: 2,
    name: 'Максим',
    email: 'max@mail.ru',
    role: 'frontend',
    status: 'blocked'
  }
]

Данные живут в памяти. После перезапуска сервера все вернется к начальному состоянию. Для тестового API это нормально, иногда даже удобно: что-то сломал - перезапустил - снова чистый набор данных.

Первый endpoint - список пользователей

Endpoint - это точка входа в API. Клиент отправляет запрос на конкретный путь, а сервер понимает, какую функцию выполнить.

В Express это выглядит так:

app.get('/users', (req, res) => {
  res.json(users)
})

Добавим запуск сервера:

app.listen(PORT, () => {
  console.log(`API is running on http://localhost:${PORT}`)
})

Запускаем:

npm run dev

Проверяем:

GET http://localhost:3000/users

Все. У нас уже есть API, которое возвращает список пользователей.

Но самое полезное начинается дальше.

Не только happy path

Многие тестовые API показывают только идеальный сценарий: запросили список - получили список.

Но в реальном интерфейсе этого мало.

Если мы хотим нормально проверить фронтенд, нам нужны разные сценарии:

• пользователь найден;
• пользователь не найден;
• форма отправлена успешно;
• форма отправлена с ошибкой;
• список пустой;
• запрос идет долго;
• сервер временно упал.

Вот это уже похоже на настоящую работу.

Получение пользователя по id

Добавим endpoint для детальной страницы:

app.get('/users/:id', (req, res) => {
  const id = Number(req.params.id)
  const user = users.find(item => item.id === id)

  if (!user) {
    return res.status(404).json({
      message: 'Пользователь не найден'
    })
  }

  res.json(user)
})

Теперь можно запросить:

GET http://localhost:3000/users/1

А можно специально открыть несуществующего пользователя и проверить, как интерфейс показывает 404.

Это маленькая вещь, но она сразу делает UI крепче.

Создание пользователя

Теперь добавим POST.

Во фронтенде это обычно нужно для форм: регистрация, заявка, комментарий, создание товара, новая задача.

app.post('/users', (req, res) => {
  const { name, email, role = 'user', status = 'active' } = req.body

  if (!name || !email) {
    return res.status(400).json({
      message: 'Поля name и email обязательны'
    })
  }

  const user = {
    id: Date.now(),
    name,
    email,
    role,
    status
  }

  users.push(user)

  res.status(201).json(user)
})

Здесь важно не только то, что мы создаем пользователя.

Важно, что мы сразу добавили ошибку 400, если не пришли обязательные поля. Потому что форма должна уметь показать не только "успешно сохранено", но и "заполни имя и email".

В документации Express отдельно напоминают: req.body приходит от пользователя, поэтому ему нельзя слепо доверять. Даже в тестовом API полезно привыкать проверять входные данные.

Пример JSON:

{
  "name": "Ирина",
  "email": "irina@mail.ru",
  "role": "manager"
}

Удаление пользователя

Для тестирования интерфейса часто нужно проверить кнопку удаления, модалку подтверждения и обновление списка после действия.

Добавим DELETE: