Разработка программного обеспечения постоянно развивается и поднимается на новые уровни. Мы начинали с машинного кода и ассемблера, перешли к императивному программированию, затем к объектно-ориентированному и функциональному. Каждый новый подход сначала сложен, но со временем оттачивается и становится основой для следующего шага. Сейчас то же самое происходит с full-stack разработкой веб-приложений.
Full-stack разработка родилась из потребностей пользователей и бизнеса
15 лет назад веб-приложения обычно генерировали полный HTML-документ на сервере для каждого действия пользователя. Популярными технологиями были JSP, PHP и ASP. Постепенно стало модно улучшать отклик интерфейса с помощью отдельных JavaScript-фрагментов для специфичных взаимодействий. Лучшие практики для таких случаев эволюционировали и воплотились в библиотеки вроде jQuery.
Подъём SPA
Пользователям понравилась мгновенная реакция интерфейса, и возникло желание всё больше переходить к обновлению UI прямо в браузере с данными с сервера. Так начали строить целые приложения — так родилась архитектура SPA (Single-Page Application).
Первые SPA строились на инструментах прошлого поколения, вроде jQuery. Не было устоявшихся практик для новых ситуаций, и разработчики пробовали разные подходы. Выводы из этих экспериментов превращались в внутренние фреймворки, которые затем эволюционировали в открытые решения, такие как React и Angular.
Распределённая природа SPA
Главная проблема традиционного SPA заключается в необходимости постоянного взаимодействия между клиентской и серверной частями приложения через сеть. Однако можно упростить эту структуру, объединяя клиентскую и серверную части в едином full-stack приложении, а не 'сшивать' их вместе, как это делают обычно. Это позволит избежать лишних сложностей, присущих SPA, и создать более целостный подход.
Эволюция full-stack подходов
Идея full-stack разработки не нова. Еще более 20 лет назад существовали решения, такие как Apache Tapestry или Millstone (предшественник Vaadin Flow), которые поддерживали асинхронные взаимодействия через JavaScript (AJAX), создавая основу для SPA-подобного опыта задолго до появления Angular или React. Новизна современной full-stack разработки заключается в том, что она становится мейнстримом, поскольку разработчики лучше понимают компромиссы, связанные с созданием SPA.
Full-stack бывает разным
Общая черта всех видов full-stack разработки — создание единого, унифицированного приложения, а не двух отдельных. Сетевое взаимодействие становится сквозной задачей, которую лучше решать на уровне фреймворка. Граница сети не разделяет приложения.
API-first разработка
Промежуточный вариант между SPA и полноценным full-stack — это API-first разработка. Вы сначала определяете формат всех сетевых сообщений и используете его для генерации клиентского кода для запросов и серверных заглушек для обработки. Это помогает держать два приложения синхронизированными. Но мышление и многие детали всё ещё основаны на предположении, что два независимых приложения общаются друг с другом.
Code-first full-stack с RPC
В противоположность этому, есть подход code-first для определения того, что отправляется по сети. Он основан на удалённом вызове процедур (RPC) по сети, а не на проектировании REST-подобных конечных точек. RPC с клиента на сервер всё ещё недостаточно для настоящего full-stack. Нужна интеграция между сервером и клиентом для общих задач, таких как маршрутизация и контроль доступа. Добавьте унифицированную сборку и поддержку двунаправленной связи по WebSockets — и получите полноценное full-stack решение, как фреймворк Hilla от Vaadin.
Серверная логика и рендеринг в full-stack
Другой вариант full-stack — это выполнение UI-логики и рендеринга на сервере, как в фреймворках Next.js или Vaadin Flow. Это упрощает модель программирования, но может вызвать дополнительные задержки и делает офлайн-режим непрактичным. Это компенсируется возможностью использовать традиционную SPA-архитектуру там, где это нужно, сохраняя full-stack подход для остального приложения. HTMX можно рассматривать как лёгкий вариант этого подхода.
Full-stack разработка как автоматическая коробка передач
Аналогии с физическим миром всегда ограничены, но можно сказать, что ручное сшивание двух независимых приложений похоже на вождение автомобиля с механической коробкой передач. Управление сцеплением и рычагом требует навыков и не обязательно для перемещения из точки А в точку Б, но многие это принимают как должное.
Раньше автоматические коробки имели компромиссы в отклике, расходе топлива и управлении в особых ситуациях. Новые решения с компьютерным управлением и системами с двойным сцеплением устраняют эти компромиссы и даже могут превосходить опытного водителя на механике.
Аналогично, full-stack разработка выиграла не только от новых технологий, таких как TypeScript и React Server Components, но и от понимания сложности, вызванной созданием двух отдельных приложений. Ещё одна параллель в том, что full-stack фреймворки часто позволяют вернуть полный контроль, как некоторые автоматы предлагают ручной выбор передач, хотя переключение остаётся автоматическим.
Full-stack позволяет сосредоточиться на бизнес-задачах
Главное преимущество автоматизации сетевого взаимодействия — сокращение времени на написание шаблонного кода и синхронизацию типов данных между двумя кодовыми базами. Это снижает риск ошибок из-за несоответствий и избавляет от необходимости проектировать API с учётом будущей совместимости. Full-stack подход позволяет фреймворкам помогать разработчику в задачах, охватывающих обе стороны сети, таких как маршрутизация и совместная работа в реальном времени.
Самое фундаментальное преимущество в том, что один разработчик может добавить новую сквозную функцию одним коммитом. Нет необходимости координировать работу между разными командами и репозиториями. Full-stack означает, что разработка организована так, чтобы решать бизнес-проблемы, а не тратить время на технические детали или согласования.
Мало того, что сокращается лишняя работа, так ещё и меньше времени уходит на ожидание следующего шага от другой команды. Меньше переключения задач, и функции можно создавать за дни, а не недели. Это позволяет бизнесу быстрее реагировать на новые инсайты. Улучшенное время выполнения даёт больше возможностей собрать обратную связь и улучшить решение, что в итоге приводит к лучшему качеству для конечного пользователя.
Full-stack — это для веб-разработки то же, что мощный монолит для backend-разработки. Он повышает продуктивность разработчиков.
Full-stack — не серебряная пуля
...потому что серебряных пуль в разработке не существует.
Одно из возражений против full-stack подхода возникает, когда приложению нужны сторонние клиенты, а значит, требуется универсальный API. Решение часто заключается в использовании подхода Backend For Frontend, позволяющего веб-приложению оставаться full-stack с встроенным слоем коммуникации.
Не всем приложениям нужен full-stack
Не всем на вебе нужны богатые, SPA-подобные взаимодействия, которые дают full-stack фреймворки или традиционные SPA. Хотя full-stack проще, чем SPA, благодаря единому приложению, есть и более простые альтернативы, такие как серверные шаблоны или статические генераторы сайтов, когда фокус на контенте, а не на взаимодействии.
Поддержка офлайн требует отдельных приложений
В противоположность, полноценная офлайн-поддержка часто требует архитектуры с двумя отдельными приложениями. Офлайн-режим также означает, что backend мог обновиться, пока пользователь был отключен, что делает явный API полезным. Это помогает управлять совместимостью, гарантируя, что старая версия клиента может общаться с новой версией сервера.
Энтузиасты и нишевые случаи
И наконец, есть энтузиасты. Возвращаясь к автомобильной аналогии, всегда будут те, кто получает удовольствие и, возможно, ностальгию от вождения машины с старой технологией. Практичность или экономия топлива для них не важны. Но это хобби для свободного времени, а не основа для успешного бизнеса по перевозкам.
Full-stack — будущее разработки веб-приложений
Как мы видели, концепция full-stack разработки опирается на отличный пользовательский опыт, который дают SPA. Она устраняет фундаментальную сложность, вызванную созданием и поддержкой двух отдельных приложений. Это помогает разработчикам использовать своё время более продуктивно, позволяя бизнесу быстрее и качественнее доставлять продукты.
Хотя full-stack разработка подходит не всегда, она часто очень хорошо соответствует задачам веб-разработки, подобно тому, как языки высокого уровня вроде Java или C# заменили C или COBOL для бизнес-приложений.
Jmix идеально подходит для full-stack разработки, предоставляя инструменты для интеграции бизнес-логики и пользовательского интерфейса в единую систему. Платформа позволяет быстро создавать веб-приложения с минимальным количеством рутинного кода, фокусируясь на функциональности