Next.js App Router спустя год в проде — кто-нибудь не пожалел?

[danila]

Год назад переехали с Pages Router на App Router в Next 14, сейчас уже 15.3. Честно, RSC дали выигрыш по first load, но половина команды до сих пор путается, где Server Component, а где Client. Кто давно на App Router — стало легче или вы тоже тонете в 'use client'?

[nullapi656]

Стало легче, но не сразу. Главный лайфхак: client-границу опускай как можно ниже по дереву, не вешай 'use client' на весь layout. У нас бандл упал процентов на 30, когда перестали тянуть всю интерактивщину наверх.

[semyon_null56]

Server Actions это хорошо ровно до момента, когда тебе нужна нормальная валидация и оптимистик апдейты. Прикрутили zod + useActionState, заработало, но кода стало больше, чем на старом добром fetch к API роуту.

[pavel_node98]

А меня бесит кэширование. В 14-й версии fetch кэшировался по умолчанию и ловили баги, что данные не обновляются. В 15 поменяли дефолты на no-store, стало предсказуемее, но миграция была болью.

[lev_cloud]

@Дмитрий_К вот да, кэш это отдельный круг ада. revalidatePath/revalidateTag вроде работают, но объяснить джуну ментальную модель почти нереально.

[neonneon5980]

Мы в итоге часть проекта оставили на чистом API + React Query, а App Router используем только там, где реально нужен SSR и SEO. Гибрид оказался спокойнее, чем тащить всё в RSC.

[kira_app10]

Использую App Router, но иногда смотрю на htmx + чуть-чуть альпайна и думаю, что мы переусложнили веб. Хотя на большом дашборде без React уже не вывезли бы, признаю.

[makar737]

Перешли на App Router в Next 14 примерно в то же время и основная боль оказалась не техническая, а ментальная — люди не могут переключиться с 'компонент это компонент' на 'компонент это либо сервер либо клиент и это не одно и то же дерево'. Помогло одно соглашение в команде: все файлы в папке /components по умолчанию client, все в /modules — server. Явная структура сильно снизила количество 'use client' в непонятных местах.

[lera_cache57]

Конкретная боль которую словили в 15.x: кэширование по умолчанию убрали в Next 15 (fetch больше не кэшируется автоматически), и код который работал на 14 начал делать лишние запросы. Если мигрируете с 14 на 15 — обязательно аудит всех fetch без явного cache: 'no-store' или next: { revalidate }. Иначе получите неожиданные расходы на API и нагрузку на бэкенд.

[bytedocker1834]

RSC реально дают выигрыш, но только если дисциплинированно не тащить в них useState/useEffect. У нас был компонент который начинался как серверный, потом кто-то добавил маленький интерактивный элемент, повесил 'use client' на весь файл — и весь бандл поехал на клиент. Хорошая практика: Server Component-обёртка, внутри маленький Client Component только для интерактивной части. Инструмент @next/bundle-analyzer очень помогает увидеть где что поехало.