Как определял баги с Backend?

Определение и диагностика багов, связанных с Backend

В современной frontend-разработке изоляция проблем, связанных именно с backend-частью приложения, является критически важным навыком. Я выстраиваю процесс диагностики по принципу отсечения внешних факторов, двигаясь от клиентского кода к сетевым взаимодействиям и только потом — к анализу ответов сервера.

Основные инструменты и этапы диагностики

1. Верификация фронтенд-логики и состояния

    Первый шаг — исключить локальные ошибки. Я проверяю:
    *   Корректность формируемых данных (состояние `store`, `props`, локальные переменные) перед отправкой запроса.
    *   Правильность составления `URL`, параметров запроса (`query params`, `body`) и заголовков (`headers`).
    *   Отсутствие ошибок в обработчиках событий и условиях, инициирующих запрос.

    Для этого активно используется отладка в браузере (`debugger`, `console.log`) и мониторинг состояния через **React DevTools** или **Vue DevTools**.

1. Анализ сетевых запросов через DevTools (Network Tab)

    Это основной инструмент. Я изучаю:
    *   **Статус ответа (`Status`)**. Коды `4xx` (ошибка клиента) и `5xx` (ошибка сервера) прямо указывают на проблему на стороне backend. `404` — неверный эндпоинт, `500` — внутренняя ошибка сервера.
    *   **Полезную нагрузку (`Payload`)**. Убеждаюсь, что `Request Payload` или `Form Data` отправляются в ожидаемом сервером формате (`JSON`, `FormData`, `multipart`).
    *   **Заголовки (`Headers`)**. Проверяю наличие и корректность обязательных заголовков (`Authorization`, `Content-Type`, `Accept`). Особое внимание — на заголовки `CORS` (`Access-Control-Allow-Origin`), их отсутствие или ошибка явно указывают на конфигурацию сервера.
    *   **Полный ответ (`Response`)**. Даже при успешном статусе `200` тело ответа (`Preview` или `Response`) может содержать бизнес-логические ошибки (например, `{ "success": false, "error": "Invalid token" }`).

1. Использование прокси-инструментов и моков

    Для подтверждения гипотезы "баг на backend" я часто **изолирую фронтенд**:
    *   Использую **мок-сервисы** (например, `json-server`) или перехватываю запросы через **Service Workers** (в библиотеке **Mock Service Worker**).
    *   Создаю эталонный "правильный" ответ и смотрю, работает ли с ним мой фронтенд. Если с моком всё работает, а с реальным API — нет, проблема локализована.

1. Совместная работа с Backend-разработчиками

    После сбора доказательств я формирую четкий **баг-репорт**, который включает:
    *   **URL** и метод запроса.
    *   **Копию корректного запроса** (из вкладки `Network`, кнопка `Copy as cURL`).
    *   **Ожидаемый** и **фактический** ответы.
    *   **Логи** или идентификатор запроса (`X-Request-ID`), если они есть.
    *   **Воспроизводимые шаги** (sequence of actions).

Пример диагностики на практике

Предположим, форма загрузки файла возвращает ошибку 400.

// Фронтенд-код (подозрительная реализация)
const uploadFile = async (file) => {
  const formData = new FormData();
  formData.append('file', file);
  // Возможная ошибка: некорректное имя поля или структура

  const response = await fetch('/api/upload', {
    method: 'POST',
    body: formData,
    // Заголовок Content-Type НЕ устанавливается явно для FormData!
    // Браузер установит его сам с boundary.
  });

  if (!response.ok) {
    throw new Error(`Upload failed: ${response.status}`);
  }
  return response.json();
};

1. В DevTools (Network):

    *   Смотрю на статус запроса: `400 Bad Request`.
    *   Во вкладке `Headers` вижу, что `Content-Type: multipart/form-data; boundary=...` установлен браузером (это правильно).
    *   Перехожу во вкладку `Payload`. Вижу, что тело запроса содержит часть `------WebKitFormBoundary...`, но структура может не соответствовать ожиданиям сервера.

1. Формирую баг-репорт для Backend-разработчика:

    *   **Эндпоинт:** `POST /api/upload`
    *   **Ошибка:** `400 Bad Request`
    *   **cURL запрос (Copy as cURL):**

    ```bash
    curl 'https://api.example.com/api/upload' \
      -H 'Authorization: Bearer ...' \
      -F 'file=@/path/to/test-image.jpg'
    ```

    *   **Гипотеза:** "Сервер ожидает поле с именем `'document'`, а фронтенд отправляет `'file'`" или "Сервер не принимает этот MIME-тип файла".

Косвенные признаки backend-багов

• Несоответствие API-контракту: Ответ не соответствует описанной в документации или TypeScript-интерфейсам схеме (лишние/недостающие поля, другой тип данных).
• Проблемы с производительностью: Долгий TTFB (Time to First Byte) при нормальном фронтенде указывает на медленные запросы к БД или тяжелую логику на сервере.
• Неконсистентное состояние: Данные, полученные с разных эндпоинтов, противоречат друг другу (например, список и детальная информация об одном объекте).
• Ошибки аутентификации/авторизации: 401/403, которые возникают при наличии валидного токена.

Итог: Мой подход систематичен. Я начинаю с предположения об ошибке на своей стороне, тщательно проверяю фронтенд, собираю неопровержимые доказательства из DevTools и только потом, с конкретными данными и способом воспроизведения, обращаюсь к команде backend. Это уважает время коллег и ускоряет фиксацию проблемы.