Фронт сломался, в консоли тихо: 3 команды для проверки API

Страница не загружает данные? Проверь API напрямую через терминал.

1. Узнать статус ответа
curl -I https://site.ru/api/users

Покажет статус и заголовки. 404 - ошиблись в адресе, 401 или 403 - проблема с доступом, 500 - упал сервер.

2. Проверить, сколько отвечает сервер
curl -sS -o /dev/null -w "HTTP %{http_code} | %{time_total}s\n" https://site.ru/api/users

Увидишь код ответа и общее время запроса. Если API отвечает несколько секунд, фронт здесь ни при чём.

3. Посмотреть запрос целиком
curl -v https://site.ru/api/users

Команда покажет соединение, отправленные заголовки, редиректы и ответ сервера. Удобно, когда браузер пишет только Failed to fetch.

Если запрос работает в терминале, но падает в браузере, дальше проверь CORS, cookie и заголовок авторизации.

Закрытая акция в честь Большой учительской недели

Большая учительская неделя пройдет с 28 сентября по 5 октября. В честь нее мы подготовили специальные скидки для участников нашей группы и их друзей.

Скидки действуют только два дня, 29 и 30 сентября.

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

Скидка 70% на базовые тарифы следующих курсов:

• Data Science с нуля
• Мобильная разработка на Android
• Программирование на Kotlin
• Системный аналитик с нуля
• Нейросети с нуля
• Frontend React
• Redis для разработчиков и DevOps
• RabbitMQ для разработчиков и DevOps
• MongoDB для разработчиков и DevOps
• Node.js с нуля
• IP-АТС Asterisk с нуля
• Сетевые технологии Huawei
• GitLab CI/CD с нуля

Скидка 60% на базовые тарифы всех остальных курсов.

Скидка 50% на все тарифы с наставником.

Все скидки рассчитываются от полной стоимости.

Промокод: SCIENTIAESTLUX

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

Сделал `git reset` и «потерял» коммит? Проверь reflog 🐸

git log показывает историю текущей ветки. git reflog показывает, куда двигался HEAD локально, в том числе после reset и rebase.

План спасения:
git reflog -n 10
найди хеш нужного состояния, затем:
git switch -c rescue <хеш>

Теперь у тебя отдельная ветка с найденным коммитом. Проверь её через git log --oneline -5 и только потом решай, переносить ли коммит в рабочую ветку через cherry-pick.

⚠️ Reflog хранится локально и не бесконечно. На другом компьютере этих записей может не быть.

Какая команда Git однажды спасла тебе день?

Мы тут с последним напоминанием

До конца закрытой акции Merion Academy осталось всего 5 часов.

Если присматривал курс себе или хотел отправить ссылку другу, сейчас последний момент. Сегодня скидки доходят до 70%, а после полуночи акция закончится.

Предложение действует только для участников нашей группы и их друзей.

Успеть выбрать курс со скидкой

Задачка с собеса: почему список в React «путает» состояние строк? 🐸

Есть список задач. У каждой строки – поле ввода. Ты сортируешь список, и текст из первой строки внезапно оказывается у другой задачи. Данные в API правильные. Где ошибка?

Частая причина – key={index}. После сортировки индекс остался на позиции, а задача на этой позиции уже другая. React переиспользовал компонент и его локальное состояние.

Исправление: key={task.id} – стабильный идентификатор самой задачи. Он должен быть уникален среди соседних элементов и не меняться при сортировке.

На собеседовании за этим обычно спрашивают дальше: где хранить состояние, когда нужен useEffect, как обрабатывать формы и запросы к API. Эти темы разбираются на курсе «Frontend-разработка на React»: компоненты, JSX, состояние, события и работа с API.

➡️ Программа курса и бесплатная часть по ссылке

Пятничная загадка: кто размножил запросы?

После небольшой правки React-страница стала открываться 8 секунд. Backend отвечает за 50 мс, база — за 20 мс, ошибок нет. В DevTools - около 150 одинаковых запросов к /api/items.

Факты расследования:
• проблема воспроизводится и в production-сборке;
• запрос запускается внутри useEffect;
• массив зависимостей эффекта заполнен;
• после каждого ответа компонент обновляет состояние;
• если убрать обновление состояния, шквал запросов прекращается.

Почему запрос запускается снова и снова?

👀 - виноват StrictMode: он дублирует запросы и в production
🔥 - в зависимостях эффекта есть объект или функция, которые создаются заново при каждом рендере
🤔 - браузер автоматически повторяет запрос, пока не получит ответ из кэша

Разгадка - в понедельник.

React отправляет запрос дважды? Сначала проверь причину 🐸

В разработке StrictMode может дополнительно запускать setup и cleanup эффекта. Это помогает заметить эффекты, которые нельзя безопасно повторить. В production такое дополнительное выполнение из-за StrictMode не происходит.

Но если запрос повторяется при каждом рендере, посмотри на зависимости:

const filters = { status: 'open' };
useEffect(() => { load(filters); }, [filters]);

Объект filters создаётся заново при каждом рендере. Для React это новая зависимость. Вынеси постоянное значение за пределы компонента или используй примитивные зависимости:

useEffect(() => { load(status); }, [status]);

И ещё: эффекту с запросом полезна отмена через AbortController, чтобы старый ответ не перезаписал свежий.

Сохрани пост на случай, когда в Network вдруг появятся одинаковые запросы.

Разгадка пятничного кейса 🐸

Одна из вероятных причин – в зависимости useEffect попал объект или функция, которые создаются заново на каждом рендере. Эффект делает запрос → ответ меняет state → новый рендер создаёт новую зависимость → эффект снова делает запрос.

Проверка: сравнить значения зависимостей между рендерами и временно заменить составную зависимость на стабильный примитив, например status или page. Если цикл исчез, источник найден. В реальном проекте возможны и другие причины; одних 150 запросов для точного диагноза мало.

А теперь короткая ловушка Python:
def add(x, items=[]):
items.append(x)
return items

Что вернут подряд add(1) и add(2)? Список по умолчанию создаётся один раз при определении функции: ответы будут [1] и [1, 2].

Безопасный шаблон:
def add(x, items=None):
if items is None: items = []
items.append(x)
return items

И в React, и в Python - всё решает момент создания значения.

Если запрос из Node.js зависает слишком долго, то ставим дедлайн

Если проект использует встроенный fetch, укажи таймаут через AbortSignal.timeout:

const res = await fetch(url, {
signal: AbortSignal.timeout(5000)
});

Через 5 секунд сигнал отменит запрос. Ошибку всё равно нужно обработать: таймаут — ожидаемый сценарий при работе с сетью, а не повод ронять весь обработчик.

try {
const res = await fetch(url, { signal: AbortSignal.timeout(5000) });
if (!res.ok) throw new Error('HTTP ' + res.status);
} catch (err) {
console.error('Запрос не выполнен:', err);
}

Важно: таймаут ограничивает ожидание на стороне клиента; он не обещает, что сервер прекратит уже начатую работу.

Есть ли таймауты у внешних API, от которых зависит ваш сервис?

Найти пользователей с шестью и более заказами — куда поставить условие? 🐸

SELECT user_id, COUNT(*) AS orders_count
FROM orders
GROUP BY user_id
HAVING COUNT(*) >= 6;

WHERE фильтрует строки до группировки. HAVING фильтрует группы после неё. Поэтому условие на COUNT(*) находится в HAVING.

Если нужны только оплаченные заказы, добавь условие раньше:

SELECT user_id, COUNT(*) AS paid_orders
FROM orders
WHERE status = 'paid'
GROUP BY user_id
HAVING COUNT(*) >= 6;

Строчка WHERE status = 'paid' убирает неоплаченные заказы до подсчёта. А HAVING оставляет пользователей, у которых оплаченных заказов шесть или больше.

Лайфхак для проверки: сначала запусти тот же запрос без HAVING и посмотри на суммы по нескольким знакомым user_id.