Выбор между традиционными веб-приложениями и одностраничными приложениями

"Закон Атвуда: любое приложение, которое можно написать на JavaScript, в конечном итоге будет написано на JavaScript".
- Джефф Атвуд

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

Используйте традиционные веб-приложения в следующих случаях.

• На стороне клиента к приложению применяются минимальные требования, например, используются только функции чтения.

• Приложение должно работать в браузерах без поддержки JavaScript.

• Ваше приложение является общедоступным и преимуществами обнаружения поисковых систем и рекомендаций.

Используйте SPA в следующих случаях.

• В приложении требуется полнофункциональный пользовательский интерфейс.

• Ваша команда знакома с JavaScript, TypeScript или BlazorWebAssembly разработкой.

• В вашем приложении должен предоставляться API для других внутренних или общедоступных клиентов.

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

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

Blazor

В ASP.NET Core имеется модель для построения многофункционального интерактивного и составного пользовательского интерфейса, которая называется Blazor. Blazor на стороне сервера позволяет разработчикам создавать пользовательский интерфейс с помощью C# и Razor на сервере, а также реализовать интерактивное подключение этого интерфейса к браузеру в реальном времени с помощью постоянного подключения SignalR. BlazorWebAssembly представляет другой вариант для Blazor приложений, позволяя им запускаться в браузере с помощью WebAssembly. Так как фактически это код .NET, запущенный в WebAssembly, вы можете повторно использовать код и библиотеки из серверных частей вашего приложения.

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

Рассмотрите возможность создания веб-приложения с помощью Blazor при следующих условиях.

• В приложении требуется полнофункциональный пользовательский интерфейс

• Ваша команда более комфортно работает с разработкой в .NET, чем с JavaScript или TypeScript

Если у вас есть приложение веб-форм, которое предполагается перенести в .NET Core или в последнюю версию .NET, вы можете ознакомиться с бесплатной электронной книгой Blazor для разработчиков веб-форм, чтобы узнать, имеет ли смысл переходить на Blazor.

Дополнительные сведения о Blazor см. в статье Начало работы с Blazor.

Когда следует выбирать традиционные веб-приложения

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

На стороне клиента к приложению применяются минимальные требования, например, используются только функции чтения

Большинство пользователей многих веб-приложений могут работать только с функциями чтения. Приложения, предназначенные исключительно или преимущественно для чтения, обычно гораздо проще тех, в которых реализуется управление большим количеством состояний. Например, в поисковой системе вполне достаточно реализовать одну точку входа с текстовым полем и вторую страницу для отображения результатов поиска. Запросы могут выполнять анонимные пользователи, в связи с чем на стороне клиента практически не требуется реализовывать логику. Аналогичным образом, публичные приложения блогов или систем управления содержимым работают преимущественно с содержимым и практически не имеют функций, реализуемых на стороне клиента. Такие приложения легко создавать в формате традиционных серверных веб-приложений, которые выполняют логику на веб-сервере и преобразовывают HTML-код для отображения в браузере. Тот факт, что каждая уникальная страница сайта имеет собственный URL-адрес, который может добавляться в закладки или индексироваться поисковыми системами (такое поведение реализуется по умолчанию и не требует добавления в приложение отдельной функции), является еще одним очевидным преимуществом такого сценария.

Приложение должно работать в браузерах без поддержки JavaScript

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

Ваша команда не знакома с принципами разработки на JavaScript или TypeScript

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

Когда следует выбирать одностраничные веб-приложения

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

В приложении требуется полнофункциональный пользовательский интерфейс

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

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

Ваша команда знакома с принципами разработки на JavaScript или TypeScript

Для создания одностраничных приложений требуется знакомство с библиотеками и принципами программирования на стороне клиента с применением JavaScript или TypeScript. Ваша команда должна быть знакома с принципами написания современных приложений на JavaScript на основе платформы одностраничных приложений, такой как Angular.

Ссылки — платформы одностраничных приложений

• Angular: https://angular.io
• React: https://reactjs.org/
• Vue.js: https://vuejs.org/

В вашем приложении должен предоставляться API для других внутренних или общедоступных клиентов

Если вы уже поддерживаете использование веб-API другими клиентами, может быть проще создать реализацию одностраничного приложения, которая использует эти API вместо воспроизведения логики на стороне сервера. Одностраничные приложения позволяют активно использовать веб-API для запроса и обновления данных во время работы пользователя с приложением.

Когда следует выбирать Blazor

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

В приложении требуется полнофункциональный пользовательский интерфейс

Как и в случае с одностраничными приложениями на основе JavaScript, приложения Blazor могут поддерживать многофункциональное поведение клиента без перезагрузки страниц. Эти приложения более отзывчивые к пользователю, поскольку извлекают только те данные (или HTML), которые необходимы для ответа на определенное взаимодействие с пользователем. Правильно созданные приложения Blazor на стороне сервера можно будет настроить на запуск в качестве приложений Blazor на стороне клиента с минимальными изменениями после того, как только эта функция будет поддерживаться.

Ваша команда более комфортно работает с разработкой в .NET, чем с JavaScript или TypeScript

Многие разработчики более продуктивно работают с .NET и Razor, чем с помощью клиентских языков, таких как JavaScript или TypeScript. Так как серверная часть приложения уже разрабатывается с помощью .NET, использование Blazor гарантирует, что каждый разработчик .NET в команде сможет понять и потенциально построить поведение внешнего интерфейса приложения.

Таблица принятия решений

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

Другие вопросы

Традиционные веб-приложения, как правило, проще и имеют лучшие критерии оптимизации поисковой системы (SEO), чем приложения SPA. Боты поисковой системы могут легко использовать содержимое из традиционных приложений, в то время как поддержка индексирования spAs может быть недостаточной или ограниченной. Если ваше приложение получает преимущества от общедоступного обнаружения поисковыми системами, это часто важно.

Кроме того, если вы не создали средство управления для содержимого SPA, разработчики могут внести изменения. Традиционные веб-приложения часто проще для разработчиков вносить изменения, так как большая часть содержимого является просто HTML и может не требовать процесса сборки для предварительного просмотра или даже развертывания. Если не разработчики в вашей организации, скорее всего, должны поддерживать содержимое приложения, традиционное веб-приложение может быть лучшим выбором.

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