lemon1964

Один из нужных слоев в платежной интеграции появляется, когда webhook перестают считать достаточной истиной сам по себе. Событие от ЮKassa еще не означает, что локальная система корректно его применила. Между этими точками есть своя логика, свои сбои и свои расхождения. Если в проекте не зафиксирован этот переход, разбирать проблемы потом приходитс…

В Next.js с Server Actions initialState легко недооценить и оставить прямо внутри компонента. Формально это работает. Но архитектурно у такого решения есть побочный эффект. UI начинает сам определять стартовую форму результата, а значит понемногу забирает на себя часть контракта, который логичнее держать рядом с action-слоем.

Один из полезных эффектов Route Handlers проявляется не в проксировании запросов, а в том, что внутри проекта появляется свой контракт ответа.

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

Одна из истин в Next.js с Server Actions, запись данных живёт только в actions. Клиентский компонент не решает, как именно сохранить сущность, куда отправить fetch, как собрать payload и как распарсить ответ. Его задача уже, показать форму, состояние pending, локальную ошибку и нужный ритм взаимодействия.

Прямой fetch из интерфейса во внешний API обычно живёт ровно до того момента, пока проект не становится чуть сложнее. Потом выясняется, что UI знает лишнее: адрес внешнего сервиса, форму чужого ответа, правила ошибок, а иногда и то, что вообще не должно выходить в браузер.

В App Router эту зависимость можно разрезать через Route Handler. Внут…

Одна из проблем в LLM-агрегаторе начинается в момент, когда список моделей загружается только один раз. Пока пользователь не обновил страницу, интерфейс продолжает жить на старом слепке каталога. Для обычного справочника это терпимо. Для LLM-слоя нет, потому что набор рабочих free-моделей у провайдера меняется заметно быстрее.

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

Один из вопросов в формах на Next.js звучит так, в какой момент ручное управление формой становится дороже, чем использование React Hook Form.

Одна из неприятных причин путаницы в Next.js состоит в том, что dev и build легко принять за два одинаковых режима, отличающихся только скоростью. На практике это не так.

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

Одна из типовых проблем формы в Next.js возникает не в submit и не в схеме валидации, а в формате ошибки. Пока все сообщения сваливаются в одну переменную, интерфейс перестаёт различать две разные вещи, ошибка конкретного поля и ошибка самой операции.