В последнее время появляется довольно много 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, и вы займетесь разбором техдолга, постарайтесь уделить больше внимания разделению проекта на независимые составляющие, выделите интерфейсы и проведите архитектурные границы. Разберитесь с «магией», которую делают сторонние компоненты — скорее всего, для вашего случая её можно реализовать более эффективно.

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