"ИИ нас всех заменит и кожаные мешки уже послезавтра будут не нужны" - это одна сторона медали. "LLM супер тупые, врут только и галлюцинируют" - вторая сторона, эквивалентная.
У всех разные стандарты, это нормально. В моей реальности в 2025 году всё-таки стыдно было бы рисовать спиннеры руками "если данные null", тригерить загрузку в useEffect, игнорировать серверные компоненты и существование хуков.
"Не все компании применяют именно tanstack-query" - это действительно так. Но всерьёз кандидатов, который не задаёт первым вопросом "а нам точно надо такой велосипед напилить", я на своих интервью не рассматриваю.
Прикольный вопрос, я бы не принял ни предложенное решение, ни сам факт существования подобного компонента. Весь мир использует tanstack-query в качестве стандарта де-факто, камон.
Если вы используете Stream в бизнес-логике - то кажется логичным использовать их и при обращении к БД
Нет, не кажется. Потому что стримы - это про backpressure, а задача приложения - достать нужные данные - и отпустить подключение к базе обратно в пул для других потребителей, и сделать это насколько быстро, насколько приложение способно. Чтобы база (которая в 99% случаев является бутылочным горлышком современных приложений) могла приступить к обслуживанию остальных потребителей.
Запрос к БД один, данных на клиенте немного
Ещё раз - ваше бутылочное горлышко - это клиент? Или база, которая держит в памяти состояние запроса, и имеет минус одно подключение из пула, пока ваш клиент неспешно перебирает записи?
Значит, выдаю народную базу по вопросу, не благодарите.
Выгорание - это, упрощённо, результат хронической усталости. Хроническая усталось возникает, когда нарушен цикл нагрузка-восстановление. Конечно, такое может случиться от хронических переработок, но это очень редкий случай: совсем не просто так впахивать достаточно долго. Чаще всего выгорание - это следствие бесконечного прокручивания в голове неотвеченных вопросов, которые вместо обдумывания (а обдумывать сложные вопросы по жизни тоже нужно сначала научиться) получают замещение думскролингом и прочей прокрастинацией.
Автор статьи дал ответ уже в заголовке - "фундамент". Фундамент может быть только один - наличие собственной картины будущего. Кто вы, чего вы хотите, куда идёте, и кем хотите стать через год. Через пять. Через десять. Много хейтят этот вопрос, но незаслуженно - потому что это очень сложный вопрос, который всё определяет. Часто очень сложно найти ответ на этот вопрос, который требует очень большой внутренней работы и опыта этой работы. Это не про постановку целей, а про знание и понимание себя.
Если ответа нет - "я прикладываю усилия, потому что где-то когда-то меня дёрнула пойти туда какая-то неосознанная потребность - со временем эта потребность не удовлетворяется - что-то идёт не так - но я не знаю, что именно, и что вообще не так - я живу день сурка - я выгораю".
Если ответ есть - "у организма есть ровно столько сил, сколько ему нужно для достижения его цели". И при любой нагрузке не выгоришь никак.
Поэтому ответ бесконечно прост (это реально так просто - либо ты знаешь, кем хочешь стать, когда вырастешь, либо нет) - и бесконечно сложно (понять свою настоящиую мотивацию и цель очень сложно, и чаще всего она будет значительно отличаться от того, что ты себе нарисовал во время очередного раунда постановки новогодних целей).
"нигде не реализован" - вполне себе где надо реализован, в т.ч. во вполне себе up-to-date-либах. Все стандартные типы совместимы (т.к. это всё ещё UUID), но алгоритм генерации, конечно, приходится втаскивать. Имхо, небольшая цена за стратегически хорошее решение.
"в 2 раза больше, чем автоинкремент" - да - но в относительном выражении, это может быть 5% размера вашей базы, если не меньше. Опять же, цена не слишком высока, и выпячивание этого факта как основного можно рассматривать как premature optimisation и кусочничанье не там где надо.
Зато вы избавляетесь от жирного нарушения архитектурных границ, а именно - ваши данные перестают зависеть от механизма выбранного движка хранения этих данных (sic!). Обычно автоинкременты сильно аукаются при рефакторинге и всяких других эволюционно-обусловленных штуках (денормализация данных, вынесение микросервиса, перенос части данных в другое более подходящее для данного паттерна доступа решение).
Ну или например, бывают ситуации, когда нужно быстро вставить в таблицу большое количество свежесгенерированных данных с релейшенами. Когда для того, чтобы вставить релейшен нужно знать id родителя, который нужно вставить до этого. С автоинкрементом я фиг знает как такое сделать (наверное, как-то можно, но я даже думать о таком отказываюсь), а с PK, которые не зависят от хранилища, это довольно простой, хоть и жирный, batch insert, который БД быстренько скушает и обработает.
Короче - автоинкременты для сайтов на вордпрессе пойдёт - но для более серьёзных продуктов имеет смысл пожертвовать небольшую цену, чтобы держать систему гибкой и поддерживаемой.
Статья вызывает вьенамский синдром. Кто Apollo (GraphQL) помянет - тому глаз вон.
Не стараюсь в критику - просто ИМХО - но я бы заменил всю статью на "просто не делайте так".
По мере роста сложности приложения главной проблемой на самом деле становится согласованность:
одна и та же сущность скачивается в пяти разных местах; при этом в каждом из этих мест нужен разный набор полей или вложенных объектов
а меняется эта сущность в трёх других местах
а ещё эта сущность может измениться в результате мутации в другой объект, который даже своим названием не намекает на такой сайд-эффект; иногда этот эффект ещё не существует, но появится через месяц в результате разработки совсем другой фичи.
В 80% случаев разработчик это увидит и поставит инвалидацию какой-то части кэша после выполнения мутации. Из оставшихся 20% - примерно половину в конце концов отловит тестирование. А ещё 10% - останется в приложении и будет накапливаться.
Конечно, есть разные стратегии по обеспечению согласованности, но все из них, что я видел, объединяет одно - они не работают, когда над проектом работает больше двух человек, или кто-то из них больше "творец", чем "ремесленник", и ему сложно удерживать в голове 100500 сложных вещей в один момент времени.
Данные можно и нужно кэшировать, и да, не через useState, а хотя-бы какой-нибудь tanstack-query или rtk (конкретно про SPA, не говорю тут про Server Components). Но - исключительно в рамках одной страницы. Перешёл на другую - лучше перезагрузить.
Не совсем по теме, но может любопытно - как раз работаю над проектом, где получилось довольно удачно на мой вкус реализовать связку фронтенд/бэкэнд через gRPC.
gRPC недоступен наружу, а React-фронтенд сделан на Next.js с app router / server functions. То есть коммуникация фронтенд-gRPC-бэкэнд происходит исключительно через внутреннюю серверную подсеть и обычный Node.js, а коммуникация браузер-фронтенд идёт через встроенные в Next механизмы. Таким образом получается использовать "нормальный" javascript gRPC без всяких прокси-шмокси.
Получилось очень удобно и эффективно (быстро писать), и работает хорошо (быстро загружаются странички), и API проектировать сильно проще становится.
Вывод из статьи - у Питонщиков свой мир (в принципе, подозревал, имея небольшой опыт работы в питонскими "инструментами"). Подключаем ML одной командой, но спотыкаемся и вынуждены придумывать алгоритм, когда нужно сделать ручную сортировку перетаскиванием. Вы всерьёз собирались писать в суппорт по этому поводу? Даже любопытно, сколько рабочих часов было потрачено на эту задачу.
По факту - алгоритмы нужны так же, как нужно в школе изучать математику и русский язык, чтобы быть программистом. Потому что нужно уметь думать, в том числе мыслить технологическими структурными элементами, уметь их в голове легко собирать и пересобирать, понимать, где у чего откуда растут ноги, и с какой стороны подойти к задаче. Да, ничего из этого не пригодится в работе, зато пригодится подвижный мозг, приученный решать определённые задачи. Знание фреймворков, навыки их поиска, выбора и быстрого впитывания документации кладутся наверх базовой алгоритмики, а не вместо неё.
С тем же успехом можно было всё то же самое сделать в одном сервисе, и запустить "onMessage" из нескольких конкурирующих потоков. Websocket тут не при чём и только сбивает с толку.
Не могу согласиться с вашей аналогией. Я не прошу людей перечислять все очереди в ивент лупе, и все интимные подробности их выполнения, оптимизации и приоритизаций. Также не предполагаю, что реально кто-то такое спрашивает, даже если и мечтает услышать. Тут речь о том, что человек понимает (или нет), что это такое, что оно делает, как оно в ноде появилось, почему оно такое как есть, и в каких случаях это оказывается важно знать.
И это не то знание, которое может быть вымыто за ненадобностью. Это понимание, которое остаётся в долговременной памяти. Вы же не забыли, что вообще понимается под "частью речи", и зачем оно нужно?
И если раньше люди, не понимающие как работает их платформа, тоже были нужны, на низкооплачиваемых должностях, решать простые типовые задачи. Сегодня они нужны в меньшей степени - потому что даже на небольших проектах никто не поймёт, почему простые задачи решаются так долго. А завтра их работу вообще будет делать ChatGPT. Поэтому по-другому никак.
"Я не задрачиваю литкод и нахватался по верхам без глубокого знания теории о том, как же на самом деле работает event-loop в node.js (как же я горю с таких вопросов, уверен, на хабре найдутся люди, которые на полном серьезе спрашивают подобное, расскажите мне, зачем). "
наблюдая за продажами со стороны аутсорс-компании, констатирую заметный IT-кризис - открытых вакансий стало меньше, IT-компании растут меньше, и т.п.
открытые позиции забиваются уволенными из фаангов бездельниками. Бездельниками, но с подтверждённым опытом в компаниях, которые точно делали хорошие продукты мирового уровня.
А тут приходит кандидат с непонятным прошлым рабочим опытом, который не знает ответов на базовые (читай - азбучные) вопросы по своему стеку, и вместо того, чтобы потратить 30 минут на чтение статьи, начинает воротить нос и сетовать на плохих интервьюверов?
Конечно, информации по первой ситуации недостаточно - тут нужно увидеть реальный кейс собеседования, и услышать, как отвечает кандидат. Но предположу, что:
Вероятно, вы плохо говорите. Или язык плохой, или культурно вы не интегрированы в западную модель коммуникации. Это сложно объяснить, но "чужой" чувствуется за километр. А сейчас, когда команды все работают удалённо, и единичные компании смогли действительно наладить этот процесс, и всё зависит от личного уровня ответственности и самоорганизации отдельного инженера, человек, у которого есть любые странности в коммуникации, даже при хороших хард-скиллах, будет отброшен.
Вероятно, вы не так хороши по хард-скиллам, как вы привыкли о себе думать. Я не задаю вопросов про Event loop на собеседованиях, но понимаю, почему они есть. Если человек работает с нодой и не почесался почитать откровенно базовые вещи про свой core stack, ИМХО - разговор можно сворачивать. Какова вероятность, что он держит руку на пульсе и следит за развитием экосистемы (которая печально известна скоростью своего развития и эволюции, и размером "зоопарка")? Какова вероятность, что он сможет разруливать сложные ситуации, связанные со спецификой работы самой ноды? Какова вероятность, что при получении задачи, он проанализирует возможные варианты решения, и сможет обоснованно выбрать наилучший? Какова вероятность того, он анализирует различные варианты структурирования исходного кода, архитектурные подходы, подходы к тестированию, и т.п.
Поэтому совет - вернитесь с небес на землю. Сегодня к собеседованиям на этом рынке нужно готовиться. В том числе "задрачиванием литкода", а также коммуникации, ответами на типовые вопросы, продумыванием нарратива о себе и своём прошлом опыте, подъёмом "матана" по systems design, чтению и запоминанию хотя-бы основной документации по своему core stack-у, сбору инфы о потенциальном нанимателе, подготовке CV под позицию, вылизыванию своего github-аккаунта и демонстрации контрибьюшенов в open source, тренировочным собеседованиям, и т.д. и т.п. Даже сегодня ищущий да обрящет, но для этого нужно перестать ныть про плохие интервью для начала.
Стоило бы, наверное, упомянуть, что использование pages в Next уже стоит считать устаревшим, и некоторое время как основным способом работы стоит считать app directory, server components и server actions.
Это довольно радикальное изменение подхода, но вроде как это наше будущее. Пробовали?
Самосознание... Что-то на кожано-мешочном.
"ИИ нас всех заменит и кожаные мешки уже послезавтра будут не нужны" - это одна сторона медали.
"LLM супер тупые, врут только и галлюцинируют" - вторая сторона, эквивалентная.
Истина посередние всегда.
Про Россию упомянули, а про РБ не сказали. В РФ 6%, а в РБ - от шести до семи. Скорее всего, с конфискацией.
У всех разные стандарты, это нормально. В моей реальности в 2025 году всё-таки стыдно было бы рисовать спиннеры руками "если данные null", тригерить загрузку в
useEffect, игнорировать серверные компоненты и существование хуков."Не все компании применяют именно tanstack-query" - это действительно так. Но всерьёз кандидатов, который не задаёт первым вопросом "а нам точно надо такой велосипед напилить", я на своих интервью не рассматриваю.
Прикольный вопрос, я бы не принял ни предложенное решение, ни сам факт существования подобного компонента. Весь мир использует tanstack-query в качестве стандарта де-факто, камон.
Нет, не кажется. Потому что стримы - это про backpressure, а задача приложения - достать нужные данные - и отпустить подключение к базе обратно в пул для других потребителей, и сделать это насколько быстро, насколько приложение способно. Чтобы база (которая в 99% случаев является бутылочным горлышком современных приложений) могла приступить к обслуживанию остальных потребителей.
Ещё раз - ваше бутылочное горлышко - это клиент? Или база, которая держит в памяти состояние запроса, и имеет минус одно подключение из пула, пока ваш клиент неспешно перебирает записи?
Значит, выдаю народную базу по вопросу, не благодарите.
Выгорание - это, упрощённо, результат хронической усталости. Хроническая усталось возникает, когда нарушен цикл нагрузка-восстановление. Конечно, такое может случиться от хронических переработок, но это очень редкий случай: совсем не просто так впахивать достаточно долго. Чаще всего выгорание - это следствие бесконечного прокручивания в голове неотвеченных вопросов, которые вместо обдумывания (а обдумывать сложные вопросы по жизни тоже нужно сначала научиться) получают замещение думскролингом и прочей прокрастинацией.
Автор статьи дал ответ уже в заголовке - "фундамент". Фундамент может быть только один - наличие собственной картины будущего. Кто вы, чего вы хотите, куда идёте, и кем хотите стать через год. Через пять. Через десять. Много хейтят этот вопрос, но незаслуженно - потому что это очень сложный вопрос, который всё определяет. Часто очень сложно найти ответ на этот вопрос, который требует очень большой внутренней работы и опыта этой работы. Это не про постановку целей, а про знание и понимание себя.
Если ответа нет - "я прикладываю усилия, потому что где-то когда-то меня дёрнула пойти туда какая-то неосознанная потребность - со временем эта потребность не удовлетворяется - что-то идёт не так - но я не знаю, что именно, и что вообще не так - я живу день сурка - я выгораю".
Если ответ есть - "у организма есть ровно столько сил, сколько ему нужно для достижения его цели". И при любой нагрузке не выгоришь никак.
Поэтому ответ бесконечно прост (это реально так просто - либо ты знаешь, кем хочешь стать, когда вырастешь, либо нет) - и бесконечно сложно (понять свою настоящиую мотивацию и цель очень сложно, и чаще всего она будет значительно отличаться от того, что ты себе нарисовал во время очередного раунда постановки новогодних целей).
Да, но давайте взглянем поближе.
"нигде не реализован" - вполне себе где надо реализован, в т.ч. во вполне себе up-to-date-либах. Все стандартные типы совместимы (т.к. это всё ещё UUID), но алгоритм генерации, конечно, приходится втаскивать. Имхо, небольшая цена за стратегически хорошее решение.
"в 2 раза больше, чем автоинкремент" - да - но в относительном выражении, это может быть 5% размера вашей базы, если не меньше. Опять же, цена не слишком высока, и выпячивание этого факта как основного можно рассматривать как premature optimisation и кусочничанье не там где надо.
Зато вы избавляетесь от жирного нарушения архитектурных границ, а именно - ваши данные перестают зависеть от механизма выбранного движка хранения этих данных (sic!). Обычно автоинкременты сильно аукаются при рефакторинге и всяких других эволюционно-обусловленных штуках (денормализация данных, вынесение микросервиса, перенос части данных в другое более подходящее для данного паттерна доступа решение).
Ну или например, бывают ситуации, когда нужно быстро вставить в таблицу большое количество свежесгенерированных данных с релейшенами. Когда для того, чтобы вставить релейшен нужно знать id родителя, который нужно вставить до этого. С автоинкрементом я фиг знает как такое сделать (наверное, как-то можно, но я даже думать о таком отказываюсь), а с PK, которые не зависят от хранилища, это довольно простой, хоть и жирный, batch insert, который БД быстренько скушает и обработает.
Короче - автоинкременты для сайтов на вордпрессе пойдёт - но для более серьёзных продуктов имеет смысл пожертвовать небольшую цену, чтобы держать систему гибкой и поддерживаемой.
Забыли добавить, что проблема использования UUID в качестве первичного ключа - фрагментация индекса (aka "проблема неравномерного индекса").
Поэтому нужно использовать UUID v7.
Конкретно в этой линии уже было несколько циклов "придумали"->"оно сдохло".
Статья вызывает вьенамский синдром. Кто Apollo (GraphQL) помянет - тому глаз вон.
Не стараюсь в критику - просто ИМХО - но я бы заменил всю статью на "просто не делайте так".
По мере роста сложности приложения главной проблемой на самом деле становится согласованность:
одна и та же сущность скачивается в пяти разных местах; при этом в каждом из этих мест нужен разный набор полей или вложенных объектов
а меняется эта сущность в трёх других местах
а ещё эта сущность может измениться в результате мутации в другой объект, который даже своим названием не намекает на такой сайд-эффект; иногда этот эффект ещё не существует, но появится через месяц в результате разработки совсем другой фичи.
В 80% случаев разработчик это увидит и поставит инвалидацию какой-то части кэша после выполнения мутации. Из оставшихся 20% - примерно половину в конце концов отловит тестирование. А ещё 10% - останется в приложении и будет накапливаться.
Конечно, есть разные стратегии по обеспечению согласованности, но все из них, что я видел, объединяет одно - они не работают, когда над проектом работает больше двух человек, или кто-то из них больше "творец", чем "ремесленник", и ему сложно удерживать в голове 100500 сложных вещей в один момент времени.
Данные можно и нужно кэшировать, и да, не через useState, а хотя-бы какой-нибудь tanstack-query или rtk (конкретно про SPA, не говорю тут про Server Components). Но - исключительно в рамках одной страницы. Перешёл на другую - лучше перезагрузить.
Не совсем по теме, но может любопытно - как раз работаю над проектом, где получилось довольно удачно на мой вкус реализовать связку фронтенд/бэкэнд через gRPC.
gRPC недоступен наружу, а React-фронтенд сделан на Next.js с app router / server functions. То есть коммуникация фронтенд-gRPC-бэкэнд происходит исключительно через внутреннюю серверную подсеть и обычный Node.js, а коммуникация браузер-фронтенд идёт через встроенные в Next механизмы. Таким образом получается использовать "нормальный" javascript gRPC без всяких прокси-шмокси.
Получилось очень удобно и эффективно (быстро писать), и работает хорошо (быстро загружаются странички), и API проектировать сильно проще становится.
Небольшая коррекция - Теория Решения Изобратательских Задач, не инженерных.
Вывод из статьи - у Питонщиков свой мир (в принципе, подозревал, имея небольшой опыт работы в питонскими "инструментами"). Подключаем ML одной командой, но спотыкаемся и вынуждены придумывать алгоритм, когда нужно сделать ручную сортировку перетаскиванием. Вы всерьёз собирались писать в суппорт по этому поводу? Даже любопытно, сколько рабочих часов было потрачено на эту задачу.
По факту - алгоритмы нужны так же, как нужно в школе изучать математику и русский язык, чтобы быть программистом. Потому что нужно уметь думать, в том числе мыслить технологическими структурными элементами, уметь их в голове легко собирать и пересобирать, понимать, где у чего откуда растут ноги, и с какой стороны подойти к задаче. Да, ничего из этого не пригодится в работе, зато пригодится подвижный мозг, приученный решать определённые задачи. Знание фреймворков, навыки их поиска, выбора и быстрого впитывания документации кладутся наверх базовой алгоритмики, а не вместо неё.
+
С тем же успехом можно было всё то же самое сделать в одном сервисе, и запустить "onMessage" из нескольких конкурирующих потоков. Websocket тут не при чём и только сбивает с толку.
Дожились, на Хабр пишет статьи ChatGPT.
Не могу согласиться с вашей аналогией. Я не прошу людей перечислять все очереди в ивент лупе, и все интимные подробности их выполнения, оптимизации и приоритизаций. Также не предполагаю, что реально кто-то такое спрашивает, даже если и мечтает услышать. Тут речь о том, что человек понимает (или нет), что это такое, что оно делает, как оно в ноде появилось, почему оно такое как есть, и в каких случаях это оказывается важно знать.
И это не то знание, которое может быть вымыто за ненадобностью. Это понимание, которое остаётся в долговременной памяти. Вы же не забыли, что вообще понимается под "частью речи", и зачем оно нужно?
И если раньше люди, не понимающие как работает их платформа, тоже были нужны, на низкооплачиваемых должностях, решать простые типовые задачи. Сегодня они нужны в меньшей степени - потому что даже на небольших проектах никто не поймёт, почему простые задачи решаются так долго. А завтра их работу вообще будет делать ChatGPT. Поэтому по-другому никак.
"Я не задрачиваю литкод и нахватался по верхам без глубокого знания теории о том, как же на самом деле работает event-loop в node.js (как же я горю с таких вопросов, уверен, на хабре найдутся люди, которые на полном серьезе спрашивают подобное, расскажите мне, зачем). "
наблюдая за продажами со стороны аутсорс-компании, констатирую заметный IT-кризис - открытых вакансий стало меньше, IT-компании растут меньше, и т.п.
открытые позиции забиваются уволенными из фаангов бездельниками. Бездельниками, но с подтверждённым опытом в компаниях, которые точно делали хорошие продукты мирового уровня.
А тут приходит кандидат с непонятным прошлым рабочим опытом, который не знает ответов на базовые (читай - азбучные) вопросы по своему стеку, и вместо того, чтобы потратить 30 минут на чтение статьи, начинает воротить нос и сетовать на плохих интервьюверов?
Конечно, информации по первой ситуации недостаточно - тут нужно увидеть реальный кейс собеседования, и услышать, как отвечает кандидат. Но предположу, что:
Вероятно, вы плохо говорите. Или язык плохой, или культурно вы не интегрированы в западную модель коммуникации. Это сложно объяснить, но "чужой" чувствуется за километр. А сейчас, когда команды все работают удалённо, и единичные компании смогли действительно наладить этот процесс, и всё зависит от личного уровня ответственности и самоорганизации отдельного инженера, человек, у которого есть любые странности в коммуникации, даже при хороших хард-скиллах, будет отброшен.
Вероятно, вы не так хороши по хард-скиллам, как вы привыкли о себе думать. Я не задаю вопросов про Event loop на собеседованиях, но понимаю, почему они есть. Если человек работает с нодой и не почесался почитать откровенно базовые вещи про свой core stack, ИМХО - разговор можно сворачивать. Какова вероятность, что он держит руку на пульсе и следит за развитием экосистемы (которая печально известна скоростью своего развития и эволюции, и размером "зоопарка")? Какова вероятность, что он сможет разруливать сложные ситуации, связанные со спецификой работы самой ноды? Какова вероятность, что при получении задачи, он проанализирует возможные варианты решения, и сможет обоснованно выбрать наилучший? Какова вероятность того, он анализирует различные варианты структурирования исходного кода, архитектурные подходы, подходы к тестированию, и т.п.
Поэтому совет - вернитесь с небес на землю. Сегодня к собеседованиям на этом рынке нужно готовиться. В том числе "задрачиванием литкода", а также коммуникации, ответами на типовые вопросы, продумыванием нарратива о себе и своём прошлом опыте, подъёмом "матана" по systems design, чтению и запоминанию хотя-бы основной документации по своему core stack-у, сбору инфы о потенциальном нанимателе, подготовке CV под позицию, вылизыванию своего github-аккаунта и демонстрации контрибьюшенов в open source, тренировочным собеседованиям, и т.д. и т.п. Даже сегодня ищущий да обрящет, но для этого нужно перестать ныть про плохие интервью для начала.
App folder подразумевает использование серверных компонентов, соотв. да, работать будет как бы точно так же, но как бы и принципиально по-другому :)
Ну и раз речь идёт о CMS, предлагаю раскрыть ещё Draft mode.
Стоило бы, наверное, упомянуть, что использование pages в Next уже стоит считать устаревшим, и некоторое время как основным способом работы стоит считать app directory, server components и server actions.
Это довольно радикальное изменение подхода, но вроде как это наше будущее. Пробовали?