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

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

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

Используйте традиционные веб-приложения, когда:

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

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

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

Используйте SPA, когда:

• Приложение должно предоставлять широкий пользовательский интерфейс с множеством функций.

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

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

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

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

Blazor

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

Blazor предоставляет новый, третий вариант, который следует учитывать при оценке того, следует ли создавать исключительно серверное веб-приложение или SPA. Вы можете создавать широкие возможности поведения на стороне Blazorклиента, такие как SPA, без необходимости в значительной разработке 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, но знакома с разработкой веб-приложений на стороне сервера, то они, вероятно, смогут доставлять традиционное веб-приложение быстрее, чем SPA. Если изучение программирования SPA не является целью, или если для работы не требуется пользовательский опыт, который предоставляет SPA, то традиционные веб-приложения являются более продуктивным выбором для команд, которые уже знакомы с их созданием.

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

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

Приложение должно предоставлять широкий пользовательский интерфейс с множеством функций.

SpAs может поддерживать расширенные клиентские функции, которые не требуют перезагрузки страницы, так как пользователи выполняют действия или перемещаются между областями приложения. SPA может загружаться быстрее, получать данные в фоновом режиме, а отдельные действия пользователей более отзывчивы, так как полная перезагрузка страницы бывает редко. SpAs может поддерживать добавочные обновления, сохраняя частично завершенные формы или документы без необходимости нажать кнопку для отправки формы. SPA могут поддерживать богатые возможности работы на стороне клиента, такие как перетаскивание, гораздо легче, чем традиционные приложения. SPA можно разрабатывать для работы в отключенном режиме, внося изменения в клиентскую модель, которые в конечном итоге синхронизируются с сервером после восстановления подключения. Выберите приложение в стиле SPA, если требования вашего приложения включают широкие функциональные возможности, которые выходят за рамки типичных предложений ФОРМ HTML.

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

Ваша команда знакома с разработкой JavaScript и (или) TypeScript

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

Ссылки — SPA Frameworks

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

Приложение уже должно предоставлять API для других (внутренних или общедоступных) клиентов.

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

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

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

Приложение должно предоставлять широкий пользовательский интерфейс

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

Ваша команда удобнее для разработки .NET, чем разработка JavaScript или TypeScript

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

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

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

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

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

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

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