В последнее время появляется довольно много Fullstack-фреймворков, они становятся популярны, их обсуждают.

Если посмотреть на результаты The State of JS 2021 в разделе «Библиотеки — Бэкенд-фреймворки», то минимум 5 из них (возможно, больше) будут как раз FullStack. Отсортировав бэкенд-фреймворки по заинтересованности, в самом верху списка мы снова увидим именно FullStack. Это понятно — они востребованы и лежат в основе разных проектов.

Однако на наш взгляд, область их применимости несколько ограничена. Почему — объясняем под катом.


Привет, Хабр! Меня зовут Александр Захаров, я backend-разработчик на Node.js в компании МойОфис. Коротко расскажу о том, как я вообще пришел к Node.js.

В начале пути, около 8 лет назад, я писал на C++, Ruby, немного на Python и еще нескольких языках. Конечно же, был в моей жизни и frontend. В JavaScript я заметил интересную особенность, которую до этого видел только у Qt — можно не опрашивать что-либо в цикле и не ждать выполнения системного вызова, а подписаться на событие и, когда оно произойдет, выполнить некоторые действия.

Чуть позже я услышу термин «реактивное программирование» и, спустя еще некоторое время, свяжу это с миром JS — мне покажется, что за этим будущее. Потом я узнаю о Node.js, перестану плеваться от асинхронных операций (в этом изрядно помогут промисы и async/await). И вот я здесь.

История повторяется

Термин «FullStack-фреймворк» появился довольно давно. Как мне кажется, это прямое следствие идеи «один код для frontend и backend», которая очень часто звучала в первые годы популярности Node.js.

Одним из ранних «больших» FullStack-фреймворков был Meteor.js. Он появился в начале 2012 года и довольно быстро стал востребованным.

Ниже я выделю аргументы, которые приводились в его пользу, и несколько их обобщу. А параллельно с этим покажу, почему эти «плюсы» не всегда оказываются полезными в реальных проектах, а иногда и мешают им.

Плюсы и минусы FullStack-фреймворков

Быстрое начало разработки: плюс

В FullStack-фреймворке уже приняты основные решения. Особенно решения, касающиеся взаимодействия frontend и backend (иначе это уже не похоже на FullStack). То есть, скорее всего, команде не придется договариваться о том, что она понимает под Rest и какой формат сообщений, посылаемый через WebSockets, правильный.

Более того, скорее всего в шаблоне приложения у вас уже будут и линтер, и настроенный TypeScript, и заранее известная структура директорий, и еще какие-нибудь приятные для взаимопонимания вещи.

В случае Meteor он еще и выберет за вас БД (это будет mongoDB).

Быстрое начало разработки: минус

Со временем появятся новые ответы на старые вопросы. Или вы наткнетесь на протекающую абстракцию какого-либо из ответов.

Хорошим примером, мне кажется, служит развитие возможностей языка. Однажды я поставил на новый компьютер свежую Node.js и решил собрать React приложение. У меня ничего не вышло — это было вскоре после появления 17 версии Node.js, и React просто не успел её поддержать. С большой долей вероятности у FullStack-фреймворка время поддержки новых версий будет больше.

Если же вы попадете на проект, где используется старый фреймворк, то он может блокировать обновление версий. С Meteor, например, не получится использовать Node.js выше 14 версии.

Быстрый ввод новичков в команду: плюс

Нового человека в команде, не знакомого с фреймворком, можно посадить на денек-другой смотреть YouTube и читать StackOverflow. Материалов много, они поданы и рассказаны интересно, технология популярна.

После пары (ну, может, тройки) дней человек уже будет знать основные принципы и сможет приступить к выполнению тасок из Jira.

На примере Meteor.js: легко найти видео «создай свой чат за 20 минут», «напиши блог за 30 минут» и тому подобное.

Быстрый ввод новичков в команду: минус

Быстрая адаптация новых сотрудников оборачивается тем, что когда фреймворк теряет популярность, люди не хотят с ним разбираться. Технология, утратившая актуальность, кажется не слишком перспективной для развития карьеры, и тратить на неё свое время не хочется. А тем более копаться в большом количестве легаси на «пещерных» технологиях.

Локальный запуск проекта: плюс

Часто бывает, что разработчик хочет запустить проект локально и поотлаживать то, что он написал.

В «традиционном» подходе сначала запускается база данных, потом разворачивается backend с livereload, потом frontend (тоже с автоматическим обновлением). Наверняка не обходится без пары компонентов в докере.

Для FullStack, как правило, есть одна команда, которая запускает весь проект с автоматическим обновлением при изменениях. И это правда довольно удобно.

Локальный запуск проекта: минус

Это случится постепенно.

Время сборки проекта будет расти. Время пересборки при обновлении одной строчки будет расти. Время установки зависимостей будет расти. Время CI будет расти. Чужие изменения будут ломать код, который, казалось бы, никак к ним не относится.

И вам захочется собирать всё раздельно. И это станет проблемой, так как код уже настолько переплелся, что найти, где заканчивается одно и начинается другое, будет почти невозможно.

Решения FullStack-задач из коробки: плюс

Некоторые задачи требуют тесного взаимодействия frontend и backend. В качестве примера можно привести переводы (i18n) и различные способы авторизации (кто пытался реализовать поддержку OAuth самостоятельно, меня поймет).

Для FullStack-фреймворков найти готовое решение таких задач обычно довольно легко. В случае же «традиционного» подхода придется разбираться.

В Meteor это реализовано его собственной системой пакетов.

Решения FullStack-задач из коробки: минус

Вскоре после того, как вы наткнетесь на сложность, обозначенную пунктом выше, вам захочется разделить код. И те самые готовые решения станут огромной частью проблемы. Как правило, их придется переписывать, но сохраняя интерфейсы. Это будет совсем не легко, и придется очень глубоко вникнуть в то, как это работает изнутри и почему именно так.

Киллер-фича: плюс

Это собирательное название для того, чем «продают» фреймворк.

  • В Meteor стали использовать довольно остроумное решение для избежания CallbackHell (напоминаю, 2012 год)

  • SvelteKit и многие другие говорят о легкости реализации SSR

  • Remix говорит, что его код можно исполнять на нодах Cloudflare

Киллер-фича: минус

Любая киллер-фича — это решение какой-либо проблемы. И у любой проблемы есть более одного решения.

  • В Node.js был выбран другой подход к решению CallbackHell, нежели тот, что предлагал Meteor. Теперь код на нем кажется странным.

  • Я верю в то, что рано или поздно можно будет отказаться от SSR ради SEO-оптимизаций и решить проблему скорости загрузки страницы за счет более быстрого интернета и использования ServiceWorker.

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

Подводя итог

Имеет ли смысл использовать FullStack-фреймворки? Безусловно, да. Быстрая разработка и заинтересованные специалисты — это просто подарок для любого проекта.

Можно ли как-то спасти себя от минусов FullStack-фреймворков? Конечно. На том этапе, когда проект перестанет быть MVP, и вы займетесь разбором техдолга, постарайтесь уделить больше внимания разделению проекта на независимые составляющие, выделите интерфейсы и проведите архитектурные границы. Разберитесь с «магией», которую делают сторонние компоненты — скорее всего, для вашего случая её можно реализовать более эффективно.

Ну и, конечно, как только появятся стандартизованные средства, для решения проблем постарайтесь использовать их.

Комментарии (17)


  1. ar2rsoft
    28.09.2022 11:20
    +2

    Быстрая адаптация новых сотрудников оборачивается тем, что когда фреймворк теряет популярность, люди не хотят с ним разбираться.


    Так если технология с более сложным входом потеряет популярность, то будет еще сложнее найти желающих в них разобраться. Да и сам сложный вход может повлиять на потерю популярности, так что это вообще аргумент в минус.


    1. ar2rsoft
      28.09.2022 12:08

      *аргумент не в минус


      1. zasonnik
        28.09.2022 12:34
        +13

        Тут дело не в сложности освоения технологии, а в поиске сотрудников, которые хотят с нею работать.

        Точнее в том, что подготовленных людей (которые хотя бы немного с ней работали) крайне мало на рынке. А изучать технологию (пускай даже довольно простую) не все потенциальные кандидаты хотят. Особенно, если по применимости они видят только правки легаси.


        1. nin-jin
          28.09.2022 12:53
          +8

          Платите нормально и они вам хоть на коболе код писать будут.


  1. nin-jin
    28.09.2022 12:55

    Довольно странно судить обо всех фреймворках по одному устаревшему их представителю, не находите?


    1. zasonnik
      28.09.2022 13:01
      +11

      Они все рано или поздно устареют. Есть какой-нибудь контр-пример?


      1. nin-jin
        28.09.2022 13:18
        -9

        Конечно, $mol.


        1. zasonnik
          28.09.2022 13:38
          +14

          Как Вы сами пишете в 2020 году:

          Прошло уже 4 года, а $mol всё ещё не современен. Он из будущего.

          Давайте посмотрим уже после того, как он преодолеет отметку "современности", и мы посмотрим на крупные поддерживаемые проекты на нем? Какими темпами они будут развиваться, какие сложности появятся?

          И еще я не уверен, что он FullStack. Но тут Вы, наверно, расскажите.


          1. nin-jin
            28.09.2022 14:21
            -6

            $mol всегда будет обгонять современные решения на пару голов.

            Тут можете глянуть вики на $mol с синхронизацией в реальном времени.


  1. maggg
    28.09.2022 14:35

    Если же вы попадете на проект, где используется старый фреймворк, то он может блокировать обновление версий. С Meteor, например, не получится использовать Node.js выше 14 версии.

    Раньше это была настоящая боль, но, по-моему, сейчас Метеор запускает ноду в ноде. То есть на машине может быть установлена последняя версия, а под капотом при запуске Метеора заведётся четырнадцатая.


  1. maggg
    28.09.2022 14:41
    +1

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


  1. Lexicon
    28.09.2022 14:54
    +6

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

    Как старый дед, сидевший на Метеоре кажется с того самого 2012 года пока не потребовалось расти дальше, скажу, что выделил бы совсем другие вещи.

    В первую очередь, в чем собственно фреймворк. Это же не только реализация, не только код, что идет в библиотеке NPM, это идеи и принципы дизайна кода и разработки.

    Для метеора можно привести в пример Optimistic UI, метеор учит вас работать с данными так, будто их мутации оптимистичны(уже произведены), что возможно благодаря подходу с изоморфным хранилищем и DDP, все, что происходит полагается на сокеты и реалтайм, а код обращается к данным так, будто они хранятся локально и актуализируются немедленно, автоматически, в момент возникновения события.

    Эти кейсы не универсальны и причина, по которой метеор дает стартовыми приложениями чаты, а не одностраничник-маркетплейса именно в особом подходе к разработке.

    Вы получаете особые инструменты, как playground для Graphql, или Redux-devtools, без которых разработка может превратиться в кошмар, а с ними, в дивный и необычный мир. Где например вполне нормально для изменений из devtool немедленно отражаться в базе, которой кстати вовсе не обязательно быть Mongo.

    С фреймворком вы так же привыкаете, что не все можно сделать его возможностями, когда-то поддержку SSR, 10-кратного прироста скорости сборки пакетов новеньким вебпаком с HMR, и даже NPM-модулей приходилось реализовывать самому, потому, что все на свете хотелось делать на Meteor. Но по честному, конечно, мир меняется вы и сами должны расти и перерастать фреймворки.

    Метеоровская команда подарила нам многие возможности фреймворка уже в виде Apollo, библиотеки вроде Grapher или Accounts перестали быть чем-то уникальным, пользователей стало привычно хранить в JWT, Mongo давно справляется с ACID, optimistic UI больше не захватывает сердца дизайнеров, а serverless давно и прочно вошел в жизнь, подружившись даже с enterprise и миллионами nginxов.

    Но вот захочется написать чат, первое, что проверю, — как там дела у Метеора.


    1. nin-jin
      28.09.2022 19:14

      Зачем снова писать чат? Возьмите готовый и кастомизируйте под себя.


      1. Lexicon
        28.09.2022 19:51


  1. mSnus
    29.09.2022 01:15

    Очень странное сравнение - full stack framework против.. отсутствия фреймворков вообще? А что мешает нынче взять отдельно фронт, отдельно бэк, и скрестить их по GraphQL? Получатся практически все плюсы и почти никаких минусов из статьи?


    1. zasonnik
      29.09.2022 10:10
      +11

      Всё же я сравниваю с разделением фронта и бэка. На самом деле, с точки зрения разработки, это правда получается дольше. Как минимум, в плане фиксации договоренностей.

      GraphQL - отличная альтернатива традиционному подходу с REST запросами. Но придется решать что делать с вебсокетами.

      В плане запуска - тоже придется что-то придумывать. Монорепозиторий? Кстати, он решит проблему шаринга интерфейсов. Но потребует дополнительного контроля в плане смешивания кода.