[Перевод] Следующий этап развития Веба27.10.2022 13:17

Основные архитектуры (в хронологическом порядке пика популярности):

1. Многостраничное приложение (Multi-Page App, MPA).
2. Прогрессивно улучшенное многостраничное приложение (Progressively Enhanced Multi-Page App, PEMPA, приложения с так называемыми «вкраплениями JavaScript»).
3. SPA.
4. Следующий этап.

Каждая архитектура веб-разработки имеет свои преимущества и недостатки. В конечном счете, недостатки становятся мотивацией для перехода к следующей архитектуре, которая также имеет свою цену.

Неважно, как мы разрабатываем приложения, нам почти всегда требуется код, выполняемый на сервере. Разница между архитектурами состоит в том, где код «живет». Изучим каждую архитектуру и посмотрим, как в течение времени менялась локация кода. При изучении архитектуры мы будем акцентировать внимание на следующих вещах:

• хранилище (persistence) — запись и чтение данных из базы данных;
• маршрутизация (routing) — направление трафика на основе адреса (URL);
• получение данных (data fetching) — извлечение данных из хранилища;
• модификация (мутация) данных (data mutation) — изменение данных в хранилище;
• логика рендеринга (rendering logic) — отображение данных для пользователя;
• обратная связь пользовательского интерфейса (UI Feedback) — ответ UI на действия пользователя.

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

MPA

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

MPA

В MPA весь код живет на сервере. Код UI на клиенте обрабатывается браузером пользователя.

Архитектурные особенности MPA

Запрос документа

Когда пользователь вводит URL в адресной строке, браузер отправляет запрос на сервер. Логика маршрутизации вызывает функцию для получения данных, которая взаимодействует с кодом хранилища для извлечения данных. Затем эти данные используются логикой рендеринга для определения страницы (HTML), которая будет отправлена в качестве ответа клиенту. Все это время браузер каким-то образом дает пользователю обратную связь о состоянии ожидания (pending state) (например, с помощью фавиконки).

Запрос на модификацию данных с перенаправлением

Когда пользователь отправляет форму, браузер сериализует (преобразует в формат JSON) данные формы, включает их в запрос и отправляет на сервер. Логика маршрутизации вызывает функцию для модификации данных, которая взаимодействует с кодом хранилища для обновления базы данных. Далее клиенту возвращается ответ с перенаправлением, на что браузер реагирует отправкой GET-запроса для получения свежего UI (это запускает процесс, аналогичный тому, что происходит при вводе пользователем URL). Снова браузер каким-то образом сообщает пользователю о состоянии ожидания.

Обратите внимание: важно, чтобы успешная мутация отправляла ответ с перенаправлением, а не новый HTML. В противном случае, в стек истории попадет POST-запрос и нажатие кнопки «Назад» в браузере приведет к повторному выполнению данного запроса.

Преимущества и недостатки MPA

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

Недостатки:

1. Полная перезагрузка страницы затрудняет реализацию некоторых вещей (например, управление фокусом), делает другие вещи непрактичными (представьте полную перезагрузку при каждом лайке твита), а некоторые — вообще невозможными (например, анимированные переходы между страницами).
2. Управление обратной связью UI. Прикольно, что фавиконка превращается в спиннер, но часто лучший пользовательский опыт (User Experience, UX) означает визуальную близость к той части UI, с которой в данный момент взаимодействует пользователь. Это то, что любят кастомизировать дизайнеры в целях брендинга.

Следует отметить, что недавно представленный Page transitions API расширяет некоторые возможности MPA. Но для большинства приложений этого все равно будет недостаточно.

PEMPA

Прогрессивное улучшение — это идея о том, что веб-приложение должно быть функциональным и доступным во всех браузерах и использовать любые возможности для улучшения UX, предоставляемые конкретным браузером. Термин PEMPA был предложен Nick Finck и Steve Champeon в 2003 году. Говоря о возможностях браузера…

XMLHttpRequest был разработан командой Microsoft Outlook Web Access в 1998, а стандартизирован только в 2016 (можете в это поверить?!). Разумеется, это никогда не останавливало производителей браузеров и веб-разработчиков. AJAX обрел популярность в 2005, и многие люди начали отправлять HTTP-запросы в браузере. Бизнес исходил из предположения, что нам требуется обращаться к серверу только за небольшой порцией данных для локального обновления UI. Это позволяло разрабатывать PEMPA.

PEMPA

«Погодите… — скажете вы. — Откуда взялся весь этот код?». Теперь мы отвечаем не только за UI в браузере, но также получили маршрутизацию, получение данных, модификацию данных и логику рендеринга на клиенте в дополнение к тому, что у нас имеется на сервере. «Что это дает?».

Дело вот в чем. Сутью прогрессивного улучшения является то, что приложение всегда должно оставаться функциональным. В начале 2000-х мы не могли гарантировать, что пользователь будет использовать браузер, понимающий AJAX, или что скорость сети пользователя позволит загрузить JS до взаимодействия пользователя с приложением. Поэтому нам нужно сохранить существующую архитектуру MPA и использовать JS для улучшения UX.

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

Кроме того, необходимо дополнить код на сервере для поддержки AJAX-запросов, отправляемых клиентом.

Это эпоха jQuery, MooTools и т.д.

Архитектурные особенности PEMPA

Запрос документа

Здесь происходит тоже самое, что при запросе документа в MPA. Однако PEMPA также загружает клиентский JS, используемый для прогрессивных возможностей, посредством добавления на страницу тегов