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

Другой видный пример адаптации разметки, возможно, лежит у вас в кармане. С первых же дней iPhone OS требовала от авторов приложений предоставить картинку default.png , которое можно сразу вывести на экран во время загрузки самого приложения.

iPhone OS принудительно загружает default.png перед запуском приложения

Другим типом действий, кроме кликов и отправки форм, которые отлично улучшаются с помощью JavaScript, является рендеринг загрузки файла .

Мы можем зарегистрировать попытку пользователя загрузить файл разными способами: drag-n-drop, вставка из буфера, выбор файла. Затем, благодаря новым HTML5 APIs , мы можем отобразить контент, как будто он уже загружен. Пример такого рода интерфейса - наша работа с загрузками в Cloudup. Обратите внимание, как миниатюра изображения генерируется и рендерится мгновенно:

Изображение рендерится и отображается до окончания загрузки

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

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

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

Но даже в этих случаях, отображение на экране спиннеров или индикаторов загрузки следует прекратить. Их нужно отображать только после того, как пользователь считатиает отклик не мгновенным. В соответствии с часто цитируемым исследованием Nielsen :

Уходит в прошлое модель передачи по HTML данных, которые остаются статичными до тех пор, пока пользователь не обновит страницу (традиционные веб-сайты) или не взаимодействует с ней (Ajax).

Ваш UI должен обновляться автоматически .

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

Представьте новостную ленту Facebook сразу после её появления, когда информацию публиковали, в основном, с персональных компьютеров пользователей. Статичный рендеринг нельзя было назвать оптимальным, но он имел смысл для людей, которые обновляли ленту, скажем, раз в день.

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

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

Однопользовательское приложение тоже может получить пользу от «реактивности»

Полезно представлять всю информацию, которая отправляется пользователю как «реактивную». Синхронизация сессии и состояния авторизации - один из примеров универсального подхода. Если у пользователей вашего приложения одновременно открыто несколько вкладок, то окончание рабочей сессии на одной из них должно сразу деактивировать авторизацию на всех остальных. Это неизбежно ведёт к улучшению безопасности и лучшей защите конфиденциальной информации, особенно в ситуациях, когда несколько человек имеют доступ к одному устройству.

Каждая страница реагирует на состоянии сессии и статус авторизации

Как только вы установили правило, что информация на экране обновляется автоматически, важно поработать над новой задачей: восстановление состояния.

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

Пример того, что происходит в случае некорректного обновления связи

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

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

Вероятно, самый раздражающий артефакт старого веба

Именно поэтому веб как платформа для приложений оставался неполноценным без JavaScript. Ajax представлял собой огромный скачок вперед с точки зрения удобства в части публикации информации пользователем.

Сейчас у нас есть множество API (XMLHttpRequest, WebSocket, EventSource, это лишь некоторые из них), которые дают полный и чёткий контроль над потоком данных. Кроме возможности публиковать пользовательские данные через форму, у нас появились новые возможности по улучшению UX.

Прямое отношение к предыдущему принципу имеет показ состояния соединения . Если мы ожидаем, что данные будут обновляться автоматически, то обязаны информировать пользователя о фактах потери связи и попытках её восстановления .

При обнаружении дисконнекта, полезно сохранить данные в памяти (а ещё лучше, в localStorage), так что их можно отправить позднее. Это особенно важно в свете будущего использования ServiceWorker , который позволяет приложениям JavaScript работать в фоновом режиме . Если ваше приложение не открыто, вы всё ещё можете продолжать попытки синхронизировать данные с сервером в фоновом режиме.

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

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

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

Предупреждение beforeunload

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

К примеру, типичную «бесконечную» страницу обычно делают с помощью кнопки на JavaScript, которая запрашивает дополнительные данные/HTML и вставляет их. К сожалению, немногие при этом помнят о необходимости вызова history.pushState или replaceState как обязательного шага.

Вот почему я использую слово «ломать». С простой моделью первоначального веба такая ситуация была невозможна. Каждое изменение состояния основывалось на изменении URL.

Но есть и обратная сторона медали - возможность улучшать историю сёрфинга, которую мы теперь контролируем средствами JavaScript.

Одну такую возможность Дэниел Пипиус назвал Fast Back :

Всё ещё остаётся несколько ситуаций, когда вы не можете контролировать поведение кеша. Например, если вы отрендерили страницу, затем ушли на сторонний сайт, а потом пользователь нажал «Назад». Этому маленькому багу особенно подвержены приложения, которые рендерят HTML на стороне сервера, а потом модифицируют его на стороне клиента:

Некорректная работа кнопки «Назад»

Ещё один способ сломать навигацию - игнорирование памяти о состоянии прокрутки. Ещё раз, страницы, которые не используют JS и ручное управление историей, скорее всего, не будут иметь тут проблем. Но динамические страницы будут. Я протестировал две самые популярные новостные ленты на основе JavaScript в интернете: Twitter и Facebook. У обоих обнаружилась амнезия на прокрутку.

Бесконечное листание страниц - обычно, признак скроллинг-амнезии

В конце концов, опасайтесь таких изменений состояния, которые релевантны только при просмотре истории. Например, этот случай с изменением состояния поддеревьев с комментариями.

Изменение вида комментариев нужно сохранять в истории

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

Во-первых, это уменьшает количество возможных ошибок и повышает надёжность. Если вы сделали важное изменение в API бэкенда, то должны обновить код клиентских программ. В противном случае, клиенты могут не воспринять новые данные или могут прислать данные в несовместимом формате.

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

Имейте в виду, что у обычного сайта обновление страницы инициирует две вещи: перезагрузка данных и перезагрузка кода. Организация системы с push-обновлениями данных без push-обновлений кода неполноценна, особенно в мире, где одна вкладка (сессия) может оставаться открытой очень долгое время.

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

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

Ещё лучший подход - «горячая» замена кода . Это значит, что не придётся осуществлять полную перезагрузку страницы. Вместо этого, определённые модули заменяются на лету, а их код повторно отправляется на выполнение.

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

Например, в нашем веб-приложении есть модуль, который устанавливает шину для передачи event’ов (как socket.io). Когда событие наступает, состояние определённого компонента меняется и это отражается в DOM. Затем вы изменяете поведение этого компонента, например, так, что он генерирует разные разметки DOM для существующего и нового состояний.

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

Но сразу возникает проблема с тем, как оценить модули без нежелательных побочных эффектов. Здесь лучше всего подходит архитектура вроде той, которую предлагает React . Если код компонента обновляется, его логика может быть просто повторно исполнена, и DOM обновляется. Объяснение этой концепции от Дэна Абрамова читай .

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

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

Немного более продвинутый метод мониторинга отслеживания движения мыши анализирует её траекторию на предмет будущего «столкновения» с интерактивными элементами, как кнопки. :

Плагин jQuery предугадывает траекторию мыши

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

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

Теги:

• latency
• производительность
• PJAX
• TurboLinks

Освойте новые мощные подходы к разработке веб-архитектуры и проектированию веб-сайтов на основе опыта взаимодействия. В книге изложен прагматический, направленный на решение задач и ориентированный на пользователя подход к планированию, проектированию и разработке динамичных веб-приложений. Вы узнаете, как извлечь максимум пользы из предметно-ориентированного проектирования, научитесь определять оптимальную вспомогательную архитектуру и освоите современные подходы к проектированию, ориентированные на опыт взаимодействия. Автор рассматривает вопросы выбора и реализации конкретных технологий, а также основные темы, связанные с опытом взаимодействия, включая проектирование мобильных веб-приложений и адаптивное проектирование. Вы научитесь максимально эффективно использовать технологии Microsoft, такие как ASP.NET MVC и SignaIR, в сочетании с другими технологиями, такими как Bootstrap, AJAX, JSON и JQuery. Используя эти технологии и освоив новую платформу ASP.NET Core 1.0, вы сможете...

Освойте новые мощные подходы к разработке веб-архитектуры и проектированию веб-сайтов на основе опыта взаимодействия. В книге изложен прагматический, направленный на решение задач и ориентированный на пользователя подход к планированию, проектированию и разработке динамичных веб-приложений. Вы узнаете, как извлечь максимум пользы из предметно-ориентированного проектирования, научитесь определять оптимальную вспомогательную архитектуру и освоите современные подходы к проектированию, ориентированные на опыт взаимодействия. Автор рассматривает вопросы выбора и реализации конкретных технологий, а также основные темы, связанные с опытом взаимодействия, включая проектирование мобильных веб-приложений и адаптивное проектирование. Вы научитесь максимально эффективно использовать технологии Microsoft, такие как ASP.NET MVC и SignaIR, в сочетании с другими технологиями, такими как Bootstrap, AJAX, JSON и JQuery. Используя эти технологии и освоив новую платформу ASP.NET Core 1.0, вы сможете быстро разрабатывать сложные веб-приложения, решающие насущные задачи и обеспечивающие отличный опыт взаимодействия.
Дино Эспозито, многократный обладатель звания Microsoft Most Valuable Professional, научит вас:
- проектировать веб-сайты и веб-приложения, отражающие реальные социальные и бизнес-процессы;
- использовать методы предметно-ориентированного проектирования для анализа и снижения сложности предметных областей;
- использовать проектирование, ориентированное на опыт взаимодействия, для уменьшения затрат и выполнения требований пользователей;
- реалистически сравнивать серверные и клиентские веб-парадигмы;
- основам новой платформы ASP.NET Core 1.0;
- упрощать разработку современных веб-страниц с помощью каркаса Bootstrap;
- практичным и эффективным приемам реализации проектов ASP.NET MVC;
- учитывать новые возможности реализации механизмов хранения и работы с моделями данных;
- понимать преимущества, недостатки и компромиссы адаптивного веб-проектирования;
- создавать истинно мобильные и оптимизированные для мобильных устройств веб-сайты.

ИЗДАТЕЛЬ PUBLISHED BY

Подразделение Microsoft Developer Division, команды разработки.NET и Visual Studio Microsoft Developer Division, .NET, and Visual Studio product teams

Подразделение корпорации Майкрософт A division of Microsoft Corporation

One Microsoft Way One Microsoft Way

Redmond, Washington 98052-6399

© Корпорация Майкрософт (Microsoft Corporation), 2019. Copyright © 2019 by Microsoft Corporation

Все права защищены. All rights reserved. Запрещается полное или частичное воспроизведение или передача настоящей книги в любом виде или любыми средствами без письменного разрешения издателя. No part of the contents of this book may be reproduced or transmitted in any form or by any means without the written permission of the publisher.

Эта книга предоставляется на условиях "как есть" и выражает взгляды и мнения автора. This book is provided “as-is” and expresses the author’s views and opinions. Взгляды, мнения и сведения, содержащиеся в этой книге, включая URL-адреса и другие ссылки на веб-сайты, могут изменяться без уведомления. The views, opinions and information expressed in this book, including URL and other Internet website references, may change without notice.

Некоторые приведенные в книге примеры служат только для иллюстрации и являются вымышленными. Some examples depicted herein are provided for illustration only and are fictitious. Все совпадения с реальными наименованиями, людьми и любыми другими предметами являются непреднамеренными и случайными. No real association or connection is intended or should be inferred.

Microsoft и товарные знаки, перечисленные на странице "Товарные знаки" на сайте https://www.microsoft.com , являются товарными знаками группы компаний Майкрософт. Microsoft and the trademarks listed at https://www.microsoft.com on the “Trademarks” webpage are trademarks of the Microsoft group of companies.

Mac и macOS являются товарными знаками Apple Inc. Mac and macOS are trademarks of Apple Inc.

Логотип Docker с изображением кита является зарегистрированным товарным знаком Docker, Inc. Используется с разрешения. The Docker whale logo is a registered trademark of Docker, Inc. Used by permission.

Все другие наименования и логотипы являются собственностью своих законных владельцев. All other marks and logos are property of their respective owners.

Стив Смит (Steve Smith) , преподаватель и разработчик программного обеспечения, Ardalis.com Steve "ardalis" Smith - Software Architect and Trainer - Ardalis.com

Редакторы: Editors:

Майра Вензел (Maira Wenzel) Maira Wenzel

NET Core и ASP.NET Core имеют ряд преимуществ по сравнению с традиционной разработкой.NET. .NET Core and ASP.NET Core offer several advantages over traditional .NET development. Используйте.NET Core для серверных приложений, если для их успешной работы вам важны некоторые или все приведенные далее аспекты: You should use .NET Core for your server applications if some or all of the following are important to your application"s success:

Поддержка разных платформ. Cross-platform support.

Использование микрослужб. Use of microservices.

Использование контейнеров Docker. Use of Docker containers.

Требования к обеспечению высокой производительности и масштабируемости. High performance and scalability requirements.

Параллельное управление версиями приложения.NET на одном сервере. Side-by-side versioning of .NET versions by application on the same server.

Эти требования поддерживаются многими стандартными приложениями.NET, но оптимизированные платформы ASP.NET Core и.NET Core обеспечивают расширенную поддержку указанных выше сценариев. Traditional .NET applications can and do support many of these requirements, but ASP.NET Core and .NET Core have been optimized to offer improved support for the above scenarios.

Все больше организаций предпочитают размещать свои веб-приложения в облаке с помощью таких служб, как Microsoft Azure. More and more organizations are choosing to host their web applications in the cloud using services like Microsoft Azure. Рекомендуется рассмотреть возможность размещения приложения в облаке, если для приложения или организации важны следующие моменты: You should consider hosting your application in the cloud if the following are important to your application or organization:

Сокращение инвестиций в центр обработки данных (оборудование, программное обеспечение, помещения, коммунальные услуги, управление серверами и т. д.) Reduced investment in data center costs (hardware, software, space, utilities, server management, etc.)

Гибкие цены (оплата за фактически используемые, а не простаивающие ресурсы). Flexible pricing (pay based on usage, not for idle capacity).

Исключительная надежность. Extreme reliability.

Улучшенная мобильность приложений, простота изменения места и способа их развертывания. Improved app mobility; easily change where and how your app is deployed.

Гибкая емкость, масштабирование в соответствии с фактическими потребностями. Flexible capacity; scale up or down based on actual needs.

Создание веб-приложений с помощью ASP.NET Core, размещенных в Azure, имеет множество конкурентных преимуществ по сравнению с традиционными альтернативами. Building web applications with ASP.NET Core, hosted in Azure, offers many competitive advantages over traditional alternatives. Платформа ASP.NET Core оптимизирована для современных методик разработки веб-приложений и сценариев размещения в облаке. ASP.NET Core is optimized for modern web application development practices and cloud hosting scenarios. В этом руководстве вы узнаете, как спроектировать приложения ASP.NET Core, чтобы максимально эффективно воспользоваться этими возможностями. In this guide, you"ll learn how to architect your ASP.NET Core applications to best take advantage of these capabilities.

Этот документ является полным руководством по созданию монолитных веб-приложений с помощью ASP.NET Core и Azure. This guide provides end-to-end guidance on building monolithic web applications using ASP.NET Core and Azure. В этом контексте монолитность означает то, что эти приложения развертываются как единое целое, а не как коллекция интерактивных служб и приложений. In this context, "monolithic" refers to the fact that these applications are deployed as a single unit, not as a collection of interacting services and applications.

Это руководство представляет собой дополнение к микрослужбам ".NET. Архитектура для упакованных в контейнеры приложений.NET " с акцентом на Docker, микрослужбах и развертывании контейнеров для размещения корпоративных приложений. This guide is complementary to the ".NET Microservices. Architecture for Containerized .NET Applications " which focuses more on Docker, Microservices, and Deployment of Containers to host enterprise applications.

• электронная книга e-book
  https://aka.ms/MicroservicesEbook
• Пример приложения Sample Application
  https://aka.ms/microservicesarchitecture

Это руководство предназначено главным образом для разработчиков, руководителей отделов разработки и архитекторов, заинтересованных в создании современных веб-приложений с помощью технологий и служб Майкрософт в облаке. The audience for this guide is mainly developers, development leads, and architects who are interested in building modern web applications using Microsoft technologies and services in the cloud.

Вторичной аудиторией являются лица, ответственные за принятие технических решений, которые уже знакомы с ASP.NET или Azure и которым требуются сведения о целесообразности обновления до ASP.NET Core для разработки новых и поддержки существующих проектов. A secondary audience is technical decision makers who are already familiar ASP.NET or Azure and are looking for information on whether it makes sense to upgrade to ASP.NET Core for new or existing projects.

Это руководство было сведено в относительно небольшой документ, в котором основное внимание уделяется созданию веб-приложений с помощью современных технологий.NET и Windows Azure. This guide has been condensed into a relatively small document that focuses on building web applications with modern .NET technologies and Windows Azure. Поэтому, чтобы получить базовое представление о таких приложениях и разобраться в соответствующих технических рекомендациях, изучите документ полностью. As such, it can be read in its entirety to provide a foundation of understanding such applications and their technical considerations. Это руководство вместе с примером приложения может быть хорошей отправной точкой или полезным справочным документом. The guide, along with its sample application, can also serve as a starting point or reference. Используйте приведенный пример приложения в качестве шаблона для собственных приложений, или чтобы увидеть, каким образом можно организовать составные части приложения. Use the associated sample application as a template for your own applications, or to see how you might organize your application"s component parts. Принимая решение о применении этих вариантов к своему приложению, вы всегда можете обратиться к описанным в руководстве принципам и направлениям архитектуры и технологическим возможностям. Refer back to the guide"s principles and coverage of architecture and technology options and decision considerations when you"re weighing these choices for your own application.

При необходимости вы можете порекомендовать это руководство членам своей команды, чтобы и они были в курсе всех важных аспектов. Feel free to forward this guide to your team to help ensure a common understanding of these considerations and opportunities. Если все заинтересованные лица будут использовать общий набор терминологии и придерживаться основополагающих принципов, архитектурные модели и практики будут применяться более последовательно. Having everybody working from a common set of terminology and underlying principles helps ensure consistent application of architectural patterns and practices.

• Выбор между.NET Core и.NET Framework для серверных приложений Choosing between .NET Core and .NET Framework for server apps

Мы бы хотели узнать ваше мнение. Укажите, о чем вы хотите рассказать нам.

Наша система обратной связи основана на принципах работы с вопросами на GitHub. Дополнительные сведения см. в .