Ну какие проблемы мы словили при массовом внедрении: - Выяснилось, что современные react разработчики очень плохо умеют с этим работать, они привыкли готовить приложения определенным образом, по шаблону и у большинства не было понимания, что такое код работающий на сервере, какие есть нюансы, как его готовить, где водораздел клиентского кода и серверного. Многие пытались на нексте соорудить привычные react-redux-mobx-whatever приложения и получался дикий оверхед и по сложности кодовой базы и по дебагу этого хозяйства. - Пытались некст горизонтально масштабировать и георезервировать - ловили кучу проблем с инвалидацией, неконсистентностью кэшей, сетевые запросы не всегда уходили куда надо. - Приложения стали этакими сцепленными монолитами, просто раскидать статику по s3 и поставить перед ними nginx уже не хватало - нужно было значительно усложнять пайплайны. - Были попытки сделать на этом всем подобие микрофронтовых оркестраторов, но тоже отказались из-за оверхеда. Ну и некст откровенно не для этого создавался. - Намучались с server actions, они тогда только появились и не все понимали как их готовить (мало кто из команды видел PHP вживую 😀 и понимал как это - отправлять данные POST обновлением страницы) Если резюмировать, то я просто понял границы nextjs и где его можно применять. И лучше не тащить в него какой-то лютый кастом и всякие модные стейт менеджеры, а просто юзать "по инструкции". Ну и просто упаковать в контейнер, а не раскидывать по CDN с кучей реверс проксей. В совокупности с каким нибудь tailwind и например при отсутствии людей на бэке (команды нет например, а делать запросы к IDP или БД надо) очень даже хороший инструмент для шаблонных приложений.