компоненты front end части разрабатываемого приложения
Простыми словами о «фронтенде» и «бэкенде»: что это такое и как они взаимодействуют
Авторизуйтесь
Простыми словами о «фронтенде» и «бэкенде»: что это такое и как они взаимодействуют
Вы наверняка уже слышали эти модные в сфере программирования слова «фронтенд» и «бэкенд», но что за ними стоит? Предлагаю в этом разобраться.
Давайте начнем с определений.
Фронтенд — все, что браузер может читать, выводить на экран и / или запускать. То есть это HTML, CSS и JavaScript.
HTML (HyperText Markup Language) говорит браузеру, каково содержание страницы, например, «заголовок», «параграф», «список», «элемент списка».
CSS (Cascading Style Sheets) говорит браузеру, как отображать элементы, например, «после первого параграфа отступ в 20 пикселей» или «весь текст в элементе body должен быть темно-серым и написан шрифтом Verdana».
4–5 декабря, Онлайн, Беcплатно
JavaScript говорит браузеру, как реагировать на некоторые взаимодействия, используя легкий язык программирования. Большинство сайтов на самом деле не используют много JavaScript, но если вы нажмете на что-то и содержимое страницы поменяется без белого мигания экрана, значит, где-то использовался JavaScript.
Бэкенд — все, что работает на сервере, то есть «не в браузере» или «на компьютере, подсоединенном к сети (обычно к Интернету), который отвечает на сообщения от других компьютеров».
Для бэкенда вы можете использовать любые инструменты, доступные на вашем сервере (который, по сути, является просто компьютером, настроенным для ответов на сообщения). Это означает, что вы можете использовать любой универсальный язык программирования: Ruby, PHP, Python, Java, JavaScript / Node, bash. Это также означает, что вы можете использовать системы управления базами данных, такие как MySQL, PostgreSQL, MongoDB, Cassandra, Redis, Memcached.
Структура взаимодействия бэкенда и фронтенда
Сегодня существует несколько основных архитектур, определяющих, как будут взаимодействовать ваши бэкенд и фронтенд.
Серверные приложения
В этом случае HTTP-запросы отправляются напрямую на сервер приложения, а сервер отвечает HTML-страницей.
Между получением запроса и ответом сервер обычно ищет по запросу информацию в базе данных и встраивает ее в шаблон (ERB, Blade, EJS, Handlebars).
Когда страница загружена в браузере, HTML определяет, что будет показано, CSS — как это будет выглядеть, а JS — всякие особые взаимодействия.
Связь с использованием AJAX
Другой тип архитектуры использует для связи AJAX (Asynchronous JavaScript and XML). Это означает, что JavaScript, загруженный в браузере, отправляет HTTP-запрос (XHR, XML HTTP Request) изнутри страницы и (так сложилось исторически) получает XML-ответ. Сейчас для ответов также можно использовать формат JSON.
Это значит, что у вашего сервера должна быть конечная точка, которая отвечает на запросы JSON- или XML-кодом. Два примера протоколов, используемых для этого — REST и SOAP.
Клиентские (одностраничные) приложения
AJAX позволяет вам загружать данные без обновления страницы. Больше всего это используется в таких фреймворках, как Angular и Ember. После сборки такие приложения отправляются в браузер, и любой последующий рендеринг выполняется на стороне клиента (в браузере).
Такой фронтенд общается с бэкендом через HTTP, используя JSON- или XML-ответы.
Универсальные/изоморфные приложения
Некоторые библиотеки и фреймворки, например, React и Ember, позволяют вам исполнять приложения как на сервере, так и в клиенте.
В этом случае для связи фронтенда с бэкендом приложение использует и AJAX, и обрабатываемый на сервере HTML.
Вне фронтенда и бэкенда
Автономный фронтенд
Веб-приложениям, которые вы собираетесь создавать, подключение к Сети будет требоваться всё меньше и меньше.
Прогрессивные веб-приложения загружаются лишь один раз и работают (почти) всегда. Вы можете хранить базу данных в браузере. В некоторых случаях вашим приложениям нужен бэкенд только при первой загрузке, а затем лишь для синхронизации / защиты данных. Такой уровень постоянства означает, что большая часть логики приложения находится непосредственно в клиенте.
Легкий бэкенд
Бэкенд, в свою очередь, становится легче и легче. Такие технологии, как хранилища документов и графовые базы данных, приводят к сокращению количества обращений к бэкенду для повторного агрегирования данных. Задача клиента — уточнить, какие данные ему нужны (базы данных графов), или извлечь все различные фрагменты данных, которые ему нужны (REST API).
Сейчас можно создавать бэкенд-сервисы, которые работают не постоянно, а только тогда, когда они нужны, благодаря бессерверным архитектурам, таким как AWS Lambda.
Размытые границы
Вычислительные задачи теперь можно перемещать между фронтендом и бэкендом. В зависимости от вида приложения можно сделать так, чтобы вычисления производились либо в клиенте, либо на сервере.
Каждый из вариантов имеет свои плюсы и минусы. Сервер — среда более стабильная, имеет меньше неизвестных, но ему постоянно нужно подключение к Сети. Некоторые пользователи используют последние версии браузеров, и им выгоднее использовать клиентские приложения, которые и делают большую часть работы, и могут похвастаться красивым интерфейсом, но тогда вы оттолкнёте пользователей, которые не используют новейшие браузеры и высокоскоростное подключение к Интернету.
В любом случае, хорошо, что есть, из чего выбирать. Главное — выбирать именно то, что лучше всего подходит для конкретной задачи. Надеюсь, у вас появилось больше понимания о том, в каком состоянии сегодня находится веб-разработка.
34 лучших инструмента для frontend-разработчика
Мы собрали 34 популярных технологий и инструментов frontend-разработчика для начинающих.
Frontend-разработка — создание удобной, красивой и эффективной клиентской части приложения. Многие новички начинают именно с этого направления программирования, изучая языки разметки — HTML и CSS, постепенно подключая JavaScript и технологии на его основе.
От выбора инструментов зависят качество и скорость работы, а определяется он задачами, которые проект решает. Допустим, большинство сайтов сегодня создается при помощи фреймворков. Но порой проект можно написать на чистых CSS, HTML и JavaScript, а не накладывать новый слой абстракции, замедляя производительность. Но хватит лирики: расскажем о самых важных инструментах, которыми должен владеть начинающий frontend-разработчик.
CSS-препроцессоры
Это надстройки над самим CSS, открывающие новые возможности языка и делающие процесс работы проще и доступнее для разработчика с помощью особых конструкций. Программисты называют их «синтаксическим сахаром».
«Синтаксический сахар» — конструкции, которые не вносят ничего принципиально нового в технологию, но делают работу с ней удобнее, проще и человечнее.
Такой код будет на 100% валидным, но выглядит ужасно. Зато с помощью препроцессора он станет таким:
Фронтенд-разработка в компании: что это и как сделать её эффективной
Мы в компании КОРУС Консалтинг СНГ уже больше десяти лет занимаемся организацией разработки веб-сервисов для наших заказчиков. У нас за плечами уже несколько десятков серьёзных проектов в банковской сфере, некоторые из них получили международное признание.
За последние два года количество команд и проектов в нашей компании увеличилось в несколько раз, при этом многократно выросла и эффективность frontend-разработки. Мы научились создавать приложения за несколько недель вместо нескольких месяцев.
Мы постоянно работаем над развитием инфраструктуры нашей фронтенд-разработки, и сегодня я поделюсь некоторыми наработками на тему организации фронтенд-подразделения, которые могут пригодиться тем, кто занимается организацией фронтенда у себя в компании.
Из этой статьи вы узнаете о нашем пути к ответам на следующие вопросы:
Что такое современный фронтенд
Фронтенд-часть сайта или приложения — это то, что вы видите у себя в браузере, эта часть активно взаимодействует с серверной (backend) частью, которая находится на каком-либо сервере, постоянно обмениваясь с ней данными.
С технической точки зрения фронтенд-часть приложения — это набор файлов, среди которых есть файлы HTML, CSS и JavaScript, картинки и т.п. Работу с CSS и HTML относят к вёрстке, JavaScript — к программированию. Оба этих направления предлагают большое количество инструментов и технологий для работы, активно развиваются и требуют большого количества знаний. Особенно это относится к JavaScript, на котором написано гигантское количество фреймворков и библиотек для «всё более эффективного» создания веб-приложений.
Как-то у меня спросили, на чём сейчас нужно делать приложения, чтобы они не устарели ещё несколько лет?
Как программист, могу дать совершенно точный и совершенно бесполезный ответ: на HTML, CSS и JavaScript. Что конкретно выбрать, jQuery, Angular или React — это уже детали.
Если углубиться в эти детали, можно дать ещё один такой же правильный и бесполезный ответ: на чём угодно. Да, это действительно так. Приложение может быть написано на чём угодно, оно будет работать, его можно будет менять и развивать.
В чём же всё-таки разница?
Чтобы найти ответ, давайте разберём, что хочет бизнес от фронтенда. Я думаю, что никого не удивлю, если скажу, что бизнес хочет быстро и недорого получить качественный результат.
Итак, на чём сейчас нужно делать приложения, чтобы разработка шла быстро, качественно и не разорила заказчика?
Скорость разработки
Программист с большим опытом работы с React сможет быстро написать приложение на React, наличие опыта работы с Angular даёт скорость работы с Angular и так далее. Всё достаточно очевидно. Сами по себе фреймворки экономят время разработки тем, что дают решения типичных проблем и задач. Эти решения по сути могут быть очень близки друг другу, и разница между ними может заключаться в синтаксисе или парадигме программирования.
Скорость разработки с использованием определённого фреймворка зависит от опыта и квалификации программистов, которые на нём пишут, сам фреймворк здесь имеет второстепенное значение.
Качество продукта
Здесь то же самое: и хорошо, и плохо можно писать на любом фреймворке. Можно заложить правильную и неправильную архитектуру куда угодно.
Всё зависит от опыта и знаний разработчика.
Стоимость
Все основные современные фреймворки бесплатны, поэтому, если опустить детали, то стоимость разработки — это стоимость времени, которое разработчики потратили на изучение требований, технологий, проработку архитектуры и написание кода. Плюс стоимость поиска/обучения этих разработчиков.
Отсюда вывод: нужно делать ставку не столько на технологии, сколько на разработчиков и организацию их работы.
Практически любой современный популярный фреймворк достаточно хорош, чтобы на нём создать практически любое приложение, которое может потребоваться современному бизнесу.
Поэтому дальше будет про эффективность фронтенда с точки зрения организации разработки.
Как это было у нас
К 2017 году у нас были приложения практически на всём, что заслуживало внимания в мире JavaScript: от jQuery до разных версий Angular и React на Typescript и Flow. Над клиентской частью наших приложений работали верстальщики и backend/fullstack-разработчики. Каждый разработчик выбирал инструменты под свои задачи, в зависимости от своих знаний фронтенд-технологий.
Сейчас я могу только предполагать, но мне кажется, что выбор фреймворков и библиотек fullstack/backend-разработчиками происходил примерно так:
«Посмотрим, что у нас пишут в интернетах. »
При выборе фреймворка/библиотеки разработчик ограничен во времени, чаще всего ему некогда самостоятельно разворачивать новые для него фреймворки и делать тестовые приложения. Поэтому он как-то делает более-менее аргументированный выбор и дальше следует в выбранном направлении.
В разные моменты времени этот выбор может быть разным даже у одного и того же разработчика (см. иллюстрации выше). При этом менее аргументированным он не становится. Чего же тогда ожидать от разных разработчиков с разным опытом?
Незаметно к 2017 году мы превратились в настоящий зоопарк фронтенд-технологий.
Фронтенд как отдельное подразделение
Большое количество разных технологий в компании — это источник рисков. Разработчик с нужными знаниями может быть занят на другом проекте, может совсем уйти из компании. Найм специалистов с большим опытом в разных направлениях — тоже занятие непростое.
Качественная документация может смягчить негативные последствия такого разнообразия, но на её изучение и погружение в незнакомые технологии обычно требуется значительное время.
В 2017 году в нашей компании появилось фронтенд-подразделение, которое стало ответом на растущие требования к качеству фронтенд-части наших проектов и к их количеству, а также попыткой стабилизировать разнообразие технологий и повысить эффективность разработки.
Это было важным этапом для развития нашей компании: то, что мы делаем сейчас, невозможно было бы сделать силами разработчиков без специализации на фронтенде.
Как вылечить зоопарк?
Неконтролируемое разнообразие технологий сильно мешает прогнозировать скорость и качество разработки в целом, тогда как коммерческая разработка требует именно этого.
Поэтому нашим следующим шагом стала унификация стека компании силами экспертов нового подразделения.
Унифицированный стек — это строго ограниченный набор библиотек и инструментов, который разработчики могут использовать при решении задач бизнеса. Также туда входит политика в отношении разных подходов в программировании, например, использование преимущественно функционального подхода, или наоборот, отказ от него.
Единый стек даёт разработчику возможность быстро переходить с одного проекта на другой, проводить кросскомандное ревью, эффективно делиться опытом и наработками с коллегами.
Главная задача здесь — не решить, что мы теперь пишем на React или Angular, а сделать так, чтобы разработчики пользовались одинаковыми инструментами для создания приложений и одинаковыми подходами к решению типовых задач.
Для справки: наш основной инструмент — React, но мы также развиваем экспертизу и в Angular.
Вот тут и начинается самое интересное. Принудиловка в мире программирования работает очень плохо.
Поэтому вместо принуждения нужно сделать так, чтобы разработчики сами хотели следовать определённым правилам разработки.
Вопрос с мотивацией мы решили следующим образом: лучше всякой документации — дать разработчику полуготовое приложение (шаблон).
Это позволяет разработчикам быстрее решать задачи и впечатлять коллег своей производительностью и одновременно побуждает их придерживаться основных правил, которые уже зашиты в коде.
С одной стороны, похожие друг на друга приложения в итоге дают значительный прирост в скорости разработки за счёт накопления опыта, готовых решений, более глубокого ревью и возможности переходить с проекта на проект. С другой стороны, у каждого проекта есть свои особенности, поэтому здесь тоже важно не перемудрить с шаблонизацией.
Что нужно заложить в шаблон приложения
При старте новых проектов разработчики обычно решают следующие типовые задачи:
Шаблон приложения, который мы разработали, закрывает первые три пункта из этого списка. Мы выразили в этом шаблоне не только наши пожелания к единому стеку для разработки, но и основные правила архитектуры приложения.
По сравнению с популярными решениями, которые находятся в открытом доступе (например, create-react-app), наш шаблон уже содержит:
Но дальше разработчика ждёт большое количество других интересных (и не очень) задач.
Выбор библиотеки компонентов
Всё, что касается вёрстки, компонентов интерфейса (выпадающих списков, календарей и т.д.), форм и валидации мы решили с помощью собственной библиотеки. Это была самая сложная часть.
В 2017 основной библиотекой компании была платная библиотека компонентов Kendo, которая предоставляла UI-решения для разных технологий, начиная с jQuery. По разным причинам она нас не устраивала, и мы решили рассмотреть альтернативные библиотеки, в том числе и вариант с созданием собственной.
Это очень важный момент, в который нужно сделать правильный выбор: найти другую библиотеку, которая нам лучше подойдёт, или создать собственную. От этого выбора зависит дальнейшее распределение ресурсов разработки и время, которое тратят команды на создание и доработку элементов интерфейса. В своём выборе мы исходили из следующих соображений.
Готовые библиотеки
Плюсы готовых библиотек:
Собственные разработки
Плюсы собственных разработок:
Получается, что приходится выбирать между установкой сразу готового функционала с кучей ограничений и разработкой собственных решений с необходимостью ждать и тратить дополнительные ресурсы на разработку.
Ни один из вариантов нас полностью не устраивал, и мы нашли другое решение.
Мы решили сделать свою надстройку над готовой библиотекой.
Напомню, что на тот момент мы уже пользовались в чистом виде библиотекой Kendo, альтернативу которой мы хотели найти. Именно её мы и решили взять за основу нашей основной библиотеки компонентов для приложений на React. А сама наша новая библиотека представляла из себя фасад над Kendo. Я опущу технические детали, скажу только, что такое решение позволило сразу получить весь функционал Kendo, а то, чего нам не хватало, в том числе и оперативное исправление багов, мы делали сами в прослойке между клиентским API библиотеки и Kendo.
Такая архитектура позволила быстро расширять количество компонентов за счёт других библиотек и модулей, просто встраивая их в нашу прослойку. Для клиентов библиотеки (для разработчиков приложений) это выглядело как быстрый прирост функционала одной библиотеки (об этом я расскажу подробно в отдельной статье).
Со временем мы заменили все компоненты на собственные реализации и выпустили вторую версию библиотеки, где учли весь предыдущий опыт, переработали API и сделали собственную документацию.
Мы решили выложить наши наработки в открытый доступ, скоро их можно будет скачать и использовать в своих проектах, следите за анонсами.
Что в итоге у нас получилось
Сейчас у нас на одном стеке и с одним набором технологий работает больше 10-ти фронтенд-разработчиков в нескольких командах. На одном стеке мы создали уже около двадцати проектов.
Статистика показывает, что эффективность работы за два года выросла более, чем в три раза. Проекты, на которые мы раньше тратили 4-6 месяцев, теперь мы делаем за 1-2 месяца (речь идёт о фронтенд-части).
Мы начали сокращать время разработки за счёт изменения структуры задач программистов. Давайте посмотрим на то, как они изменились.
Я уже приводил список задач, которые решали разработчики два года назад:
Это сказалось не только на скорости работы, но и в целом на настроении разработчиков. Как ни крути, реализация бизнес-логики куда интереснее, чем настройка выпадающих списков. Проджект-менеджеру также гораздо проще объяснить заказчику, что неделя рабочего времени была потрачена на разработку важных бизнес-фич, а не на то, что потребовалась доработка небольшого элемента интерфейса, хотя по трудозатратам они могут быть вполне равнозначными.
Мы продолжаем работу в выбранном направлении и одна из основных задач на ближайшее будущее — повышение мотивации разработчиков к углублению компетенций в выбранном стеке и к поиску новых эффективных решений. Масштабирование таких решений на всю компанию теперь не составляет особого труда благодаря общей библиотеке и шаблону приложения.
С пожеланиями эффективности и до новых встреч!
Современные архитектуры фронт-энда
В статье «Contemporary Front-end Architectures» рассмотрены архитектуры фронт-энда с точки зрения потоков данных в исторической ретроспективе.
Материал состоит из трех частей
Часть 1. Теория и история
Логическое обоснование потоков данных в различных компонентах программной системы является центральной идеей архитектуры программного обеспечения.
Мерой качества того или иного архитектурного решения является легкость, с которой вы можете аргументировать это обоснование!
Изучение потоков данных и, в конечном счете, архитектур в современных веб-приложениях — цель данной статьи. Веб-приложения превратились из простых статичных веб-сайтов (двухуровневая архитектура) в сложные многослойные SPA и SSR системы с доступом к информации по API. Системы CMS превратились в системы без визуально-презентационного уровня.
Сообщество фронт-энда изменилось быстро в последнее время. Все началось с методов, воздействующих на DOM, представленных jQuery, которая быстро сменилась Backbone.js на основе MVC. И мгновенно мы оказались в джунглях архитектуры двунаправленных и однонаправленных потоков данных. Где-то мы потеряли след того, как мы сюда попали. Как мир, залитый в MVC, внезапно попал в однонаправленный поток данных React? Какая корреляция? По мере продвижения мы попытаемся разгадать эту головоломку.
Несмотря на то, что статья предназначена для фронт-энд разработчиков, она должна помочь любому веб-девелоперу, которого интересует общее представление о современной архитектуре веб-приложений. Архитектура программного обеспечения лежит в основе большого количества действий — процесса, сбора требований, топологии развертывания, технологического стека и т.д. Однако это выходит за рамки данной статьи.
Необходимая прелюдия — что такое компьютер?
Здесь нужна прелюдия. Компьютер — это машина, которая собирает данные/информацию от пользователя и передает ее пользователю после ее обработки, мгновенно или с задержкой. Как компьютер собирает и показывает эти данные? Для этого используется программное приложение.
Задача архитектуры программного обеспечения заключается в предоставлении разумных средств для создания программного обеспечения без потери здравого смысла.
Главное, что нужно помнить, это то, что данные, которые обрабатывает программное приложение, известны как Модель (Model) или Состояние приложения (Application state). Некоторые называют это «Моделью предметной области» (Domain model) или «Бизнес-логикой» (Business logic) приложения. Приложение может быть настольным или веб-приложением.
На протяжении всей статьи мы будем стремиться понять разумные способы представления этого состояния приложения пользователю (веб-интерфейса) без потери здравомыслия. Мы рассмотрим, как данные передаются от модели к слою представления.
MVC предков — Первоисточник
Отделение данных от представления является основной темой графических пользовательских интерфейсов (как веб-ориентированных, так и настольных). С MVC — Model View Controller, отделение представления (View) от доменной области (Model) было основной мотивацией проектирования. И, без сомнения, MVC была плодотворной работой, которая повлияла на будущие поколения.
Если существует первый принцип разработки программного обеспечения, то это наверняка принцип SoC (Separation of Concern) — разделения ответственностей. И, вероятно, паттерн MVC является его первой манифестацией.
MVC был представлен для Smalltalk-80. В MVC объект View отображает данные, хранящиеся в объекте Model. Прежде чем мы сможем полностью изучить потоки данных в MVC, мы должны понять среды прикладных программ того времени (около 1970-х годов):
Эти ограничения имели важные последствия для MVC. Обязанностью объекта Controller стало реагирование на пользовательские вводы, такие как клавиатура или мышь, и их преобразование в действия над моделью. Кроме того, отсутствие графических элементов в операционных системах означает, что Представление (View) не соответствует тому, что на экране.
Скорее, Представление и Контроллер существовали как пара. Представление показывало пользовательский вывод, а Контроллер получал входные данные от пользователя. Следует отметить, что пара Представление-Контроллер существовала для каждого элемента управления на экране, что дает нам раннюю концепцию виджета.
Сегодня в React, Vue или Angular эта View-Controller пара концептуально совпадает с компонентом, хотя точная механика отличается в зависимости от состояния обработки.
После всего сказанного о MVC, следующее изображение должно иллюстрировать потоки данных в MVC. В этом примере у нас есть простой счетчик с кнопкой увеличения и уменьшения. Состояние счетчика поддерживается Моделью. Также мы заменили две кнопки на одну, чтобы было проще.
С точки зрения связей:
View и Controller содержат прямую ссылку на Model, но не наоборот. Это означает, что Model не зависит от пользовательского интерфейса и может меняться, не беспокоясь о проблемах пользовательского интерфейса.
Модель реализует шаблон Observer, и на него подписывается один или несколько объектов View. Когда Model изменяется, она вызывает событие, и View обновляется после реакции на событие.
В MVC есть два разных потока данных. Во View-потоке Model не участвует. Это только изменение пользовательского интерфейса. Показ эффекта нажатия кнопки или реакция на событие прокрутки мыши — пример View-потока.
Сегодня мы больше не используем этот MVC и поэтому иногда его называют классическим MVC или MVC предков (father’s MVC).
Двигаемся к Модели приложения (Application model)
Вскоре стало понятно, что Application State не может быть полностью изолирован от GUI. Всегда существует какая-то логика представления (Presentation logic) или состояние представления (View state), которые необходимо поддерживать.
Сложные графические интерфейсы нуждаются в дополнительном состоянии, которое существует только для помощи виджетам пользовательского интерфейса и обеспечения лучшего взаимодействия с пользователем.
Но это может вызвать проблемы. Давайте возьмем наш предыдущий пример счетчика. Когда наш счетчик достигнет 10, мы должны изменить цвет метки с черного на красный, чтобы указать предупреждение. Такое поведение изменения цвета на самом деле не является бизнес-логикой или задачей. Это чисто эстетическая часть (UX), которая должна быть учтена. Настоящий вопрос — где? Это должна быть Модель или Представление?
Поскольку эта Логика представления или Состояние представления в основном представляет собой состояние, полученное из Модели предметной области, оно должно поддерживаться в Модели. Но Модель предметной области, поддерживающая визуальный аспект, — то есть красный цвет — по определению не очень хорошо. Если же мы поместим это в объект Представление, то это создаст еще один набор проблем. Наш виджет больше не является шаблонным. Мы не можем использовать его в другом месте. Кроме того, добавление условия с жестко закодированным числом 10 в наш объект View означает, что мы ограничиваем некоторую часть бизнес-логики.
Чтобы решить эту проблему, в исходную MVC была добавлена еще одна сущность — Модель приложения (Application Model, AM). Как видно на рисунке, с Моделью приложения пара View-Controller не имеет прямого доступа к модели. Вместо этого они регистрируются в событиях Модели приложения и используют его для доступа к необходимым данным.
Потоки данных остаются такими же, как и у классического MVC. Конечно, у каждой модели есть свои плюсы и минусы, и AM-MVC не исключение. Наиболее заметная проблема заключается в том, что Application Model не имеет прямой ссылки на объект View и, следовательно, не может манипулировать им напрямую, даже если Application Model предназначена для поддержания состояния View.
В общем, введение Модели приложения отодвигает конкретное состояние Представления от доменной области и помогает упростить объекты Представления за счет уменьшения их сложности. Это очень похоже на Модели представления (Presentation Model), концепцию, придуманную Мартином Фаулером в его оригинальном исследовании.
Суть Модели представления заключается в полностью автономном классе, который представляет все данные и поведение окна пользовательского интерфейса, но без каких-либо элементов управления, используемых для отображения этого пользовательского интерфейса на экране. Затем представление просто проецирует состояние модели представления на стекло.
Эпоха современной архитектуры настольных систем
Продолжаем двигаться дальше по времени и все меняется. Новый тип операционных систем набирает полную силу. Приложения отошли от «железа» компьютеров. Полноценное ядро, драйверы ОС и утилиты появились между ними. Операционные системы на основе графического интерфейса, такие как Windows, предоставляли готовые виджеты сразу после инсталляции.
Контроллерам больше не нужно было слушать устройства ввода. Идея Представления (View) объекта изменилась.
Большая часть функциональности Контроллера была взята на себя операционной системой. Идея View трансформировалась. Раньше это был единственный виджет. Теперь это была композиция виджетов. Представление могло содержать другое представление. Представление стало двунаправленным в том смысле, что оно реагировало на действия пользователя, а также отображало данные модели.
Идея View в мире фронт-энда очень похожа на эту идею View. В контексте Интернета Представление — это целая страница.
Классический MVC становился устаревшим и неудобным в использовании. Чтобы приспособиться к этим изменяющимся средам, команда Dolphin искала новую модель создания пользовательских интерфейсов. Это был 1995 год. История того, как команда Dolphin достигла нового дизайна, очень хорошо задокументирована здесь и здесь. Мы не будем останавливаться на этом.
В итоге, команда проделала поворот модели MVC на 60 градусов, которую они назвали «Скручивание триады» (Twisting the triad). Так мы получили MVP.
С точки зрения связей:
Презентер (Presenter) следит за логикой Представления. Презентер может изменить Представление напрямую. Представление делегирует пользовательские события Презентеру.
В зависимости от реализации, Представление подписывается на Модель и полагается на Презентер для сложной логики, или Представление просто полагается на Презентер для всего.
Как отмечалось в его работах по архитектуре графического интерфейса, Мартин Фаулер разделил реализацию MVP на Supervising Controller MVP и Passive View MVP. Различия и потоки данных поясняются на диаграмме.
MVVM — Model View ViewModel
MVP великолепен, и для него есть много возможных вариантов и сложных деталей, но с точки зрения фронт-энда MVVM действительно выделяется. В некоторых реализациях он также известен как Model-View-Binder. MVVM очень похож на Passive View MVP, но с добавленной особенностью привязки данных (data binding). Это техника программирования, которая связывает данные поставщика и потребителя вместе и синхронизирует их. Она избавляет от большого количества стандартного кода, который нам традиционно необходим для синхронизации View и Model. Это позволяет работать на гораздо более высоком уровне абстракции.
С точки зрения связей:
ViewModel — это объект, который предоставляет связываемые (bind-able) свойства и методы, которые используются View.
MVVM имеет дополнительный элемент Binder, который отвечает за синхронизацию View с ViewModel. Каждый раз, когда свойство ViewModel изменяется, Представление автоматически обновляется, чтобы отразить изменения в пользовательском интерфейсе.
Data binding, присущая MVVM, стала основой многих интерфейсных библиотек, включая Knockout, Angular, Vue.js, React и другие.
Мы еще раз вернемся к привязке данных в разделе веб-приложения.
В царство веб-приложений
По аналогии с оригинальный MVC, появился шаблон для использования с веб-приложениями. Он известен как Web MVC. На самом деле, из-за того, как веб-приложения создаются и разворачиваются, MVC является для них более естественным развитием, чем для настольных приложений.
Основная путаница в сообществе заключается в том, что настольные MVC и web-MVC — это две разные модели. Если бы web-MVC был бы назван как-то иначе, все было бы намного проще.
Веб-приложение является категорией распределенных приложений. Хотя MVC довольно естественен для веб-приложений, в целом создавать распределенные приложения довольно сложно. Некоторая часть кода выполняется на сервере, в то время как другая на клиенте — то есть в браузере.
При построении архитектуры крупных масштабируемых веб-приложений основная задача состоит в определении, где должна выполняться каждая часть кода. На двух концах у нас расположены серверные приложения и насыщенные клиентские (rich client-driven) приложения. Между ними мы можем варьировать бесконечным числом способов.
Говоря о веб-приложении в контексте MVC, существует три отдельных цикла данных и, следовательно, три реализации MVC: MVC на стороне сервера, внутренний MVC браузера и фронт-энд MVC. Браузер является посредником между тремя типами взаимодействия:
Браузер имеет собственную Модель, Вид и Контроллер. Как разработчикам, нам не нужно беспокоиться об MVC браузере.
Серверная MVC a.k.a. Модель 2
Первой известной реализацией серверной MVC является Модель 2 от Sun Microsystems для веб-приложений на Java.
Этот MVC очень похож на классический MVC, но появляются дополнительные сложности, связанные с тем, что время цикла потока данных увеличивается экспоненциально, когда данные пересекают границы клиента и сервера. Некоторые вещи, на которые стоит обратить внимание:
Считается, что сегодня SSR (Server Side Rendering) — рендеринг на стороне сервера означает совершенно другую концепцию. Однако это не совсем так. Поскольку весь HTML/контент создается сервером, а клиентский код JavaScript не используется, веб-приложения, полностью созданные с использованием серверной MVC, все еще рассматриваются как SSR.
Выходим за пределы серверной части
Вот где действительно становится интересно. Почти все браузеры начали реализовывать в себе движки JavaScript. На мой взгляд, именно AJAX изменил ход веб-приложений. Google первым освоил его с помощью своего почтового клиента и картографических приложений.
Мир серверной MVC, генерирующей HTML + JavaScript. Код JS разбросан по страницам. JavaScript в основном используется для улучшения UX за счет сокращения циклов просмотра сервера (Server View Cycles). Такие вещи, как отправка формы, проверка ввода и т.д. обрабатываются клиентским кодом.
Это самая распространенная архитектура в истории веб-приложений. Большинство приложений B2C, SEO-дружественных веб-сайтов, особенно созданных с помощью CMS — Content Management Systems, используют его. Количество клиентского кода зависит от потребностей приложения.
Эта архитектура как таковая никогда не была действительно стандартизирована и поэтому не имеет названия. Она развивалась инкрементном стиле и до сих пор считается расширением Web MVC. ASP.NET MVC, Java Struts, Python Django, Ruby ROR, PHP CodeIgniter — некоторые из широко используемых сред, широко использующих серверную MVC или Web MVC.
Конечно, существует много других вариаций этого стандартного шаблона, но они не оказывают реального влияния на современные архитектуры фронт-энда и могут быть опущены.
RIA — архитектура насыщенных интернет-приложений (Rich Internet Application Architecture)
Учитывая всё вышесказанное, мы теперь готовы обсудить современные архитектуры фронт-эндов. Современные фронт-энд архитектуры крутятся вокруг создания RIA — Rich Internet Application. Точное определение RIA невозможно, поскольку оно означает разные вещи. Но в целом RIA или Rich Web Applications — это категория приложений, в которых приложение сильно зависит от кода на стороне клиента, а их UX очень близок к приложению для настольных компьютеров. Они в основном создаются с использованием фреймворков, поддерживающих SPA (Single Page Application) — одностраничное приложение. Поток данных цикла просмотра сервера из Web MVC не существует. Обычно существует только одна исходная HTML-страница, а затем для визуализации последующих страниц используются код на стороне клиента и системы маршрутизации.
Построение RIA — сложная операция, которая возникла в результате изучения предыдущих архитектур графического интерфейса для настольных компьютеров. ViewModel, Observers, Components и т.п. являются примерами понятий, которые заимствованы из этих архитектур. Oliver Steel, в своем посте 15-летней давности (поверьте мне, это превосходная статья) разработал хорошую справочную архитектуру для понимания потоков данных RIA.
Наиболее заметным отличием справочной архитектуры RIA от Web MVC является отсутствие Controller и View в архитектуре верхнего уровня. Однако они не ушли в буквальном смысле. Если мы посмотрим под поверхность, то Controller и View все еще присутствуют, но утончаются, их роли значительно уменьшаются. Бэк-энд реализуется, в основном, как API-сервис. Работа Представления сводится к созданию JSON, а Контроллер отвечает за принятие входящих запросов и их распределение соответствующим бизнес-процессам.
Шаблоны GUI сложны?
Если вы подробно изучили предыдущие шаблоны (Patterns), то поймете, что шаблоны GUI отличаются от других шаблонов разработки программного обеспечения. Возьмем, например, элементы многоразового объектно-ориентированного программного обеспечения (Elements of Reusable Object-Oriented Software). Большинство шаблонов не зависят от технологии или языка программирования. Однако то же самое не относится к шаблонам GUI.
Шаблоны GUI используются на границе HCI (Human Computer Interaction) — взаимодействие человека с компьютером. Пользователь (User) и побочный эффект (Side Effect) являются неотъемлемой частью шаблона.
Таким образом, практически невозможно обсуждать их в теории, не принимая во внимание фреймворки и языки программирования. До сих пор, с достаточно высоким уровнем абстракции, мы могли исследовать эти паттерны. Но по мере приближения к сути статьи мы будем отталкиваться от различных библиотек или структур для описания этих шаблонов.
Большинство шаблонов веб-интерфейса можно разделить на три этапа: эволюционный, революционный и современный.
Эволюционные шаблоны являются просто расширением серверной MVC. Они действительно не пытаются изобрести что-то новое. Они дополняют существующие приложения, улучшая свой UX шаг за шагом.
В то время как революционные шаблоны — это те идеи, которые отделяют разработку интерфейсных приложений от управляемых сервером рабочих процессов. Их прибытие отмечает известность SPA-приложений.
Современные шаблоны похожи на продвинутую версию этих революционных моделей и являются неким общим трендом, в сторону которого движется фронт-энд сообщество.