Я хочу представить 7 действенных принципов для веб-сайтов, которые хотят применить JavaScript для управления UI. Эти принципы являются результатом моей работы как веб-дизайнера, но также как давнего пользователя WWW.
JavaScript бесспорно стал незаменимым инструментом для разработчиков фронтенда. Сейчас сфера его применения расширяется на другие области, такие как серверы и микроконтроллеры. Этот язык программирования выбрали престижные университеты, чтобы обучать студентов основам информатики.
В то же время существует ряд вопросов относительно его роли и конкретного использования, на которые многие затрудняются ответить, в том числе авторы фреймворков и библиотек.
- Должен ли JavaScript использоваться как замена функциям браузера: история, навигация, рендеринг?
- Умирает ли бэкенд? Нужно ли вообще рендерить HTML?
- Правда ли, что будущее за приложениями на одной странице (Single Page Applications, SPA)?
- Должен ли JS генерировать страницы на веб-сайте и рендерить страницы в веб-приложениях?
- Нужно ли использовать техники вроде PJAX или TurboLinks?
- Каково точное отличие между веб-сайтом и веб-приложением? Должно ли остаться что-то одно?
Далее последуют мои попытки ответить на эти вопросы. Я попытался исследовать, как использовать JavaScript с точки зрения пользователя (UX). В частности, уделил особое внимание идее минимизации времени, которое требуется пользователю для получения интересующих его данных. Начиная с основ сетевых технологий и заканчивая предсказанием будущего поведения юзера.
1. Рендеринг страниц на сервере
tl;DR: Рендеринг на сервере осуществляется не ради SEO, а для производительности. Принимайте в расчёт дополнительные запросы для получения скриптов, стилей и последующие запросы к API. В будущем, принимайте в расчёт использование метода HTTP 2.0 Push.
Прежде всего, я вынужден обратить внимание на общепринятую ошибку разделять «приложения с рендерингом на сервере» и «одностраничные приложения». Если мы хотим добиться наилучшего восприятия с точки зрения пользователя, то не должны ограничивать себя такими рамками и отказываться от одной альтернативы в пользу другой.
Расстояние между Стэнфордом и Бостоном 4320 км.
Скорость света в вакууме 300 x 10^6 м/с.
Скорость света в оптоволокне составляет примерно 66% скорости света в вакууме.
Скорость света в оптоволокне 300 x 10^6 м/c * 0,66 = 200 x 10^6 м/c.
Односторонняя задержка при передаче в Бостон 4320 км / 200 x 10^6 м/c = 21,6 мc.
Задержка при передаче туда и обратно 43,2 мc.
Пинг из Стэнфорда в Бостон в интернете современного образца около 85 мс (…)
Итак, современное оборудование интернета передаёт сигнал со скоростью 0,5 от скорости света.
Указанный результат 85 мс можно улучшить (и уже сейчас он чуть лучше), но важно понять, что существует физическое ограничение на задержку при передаче информации через интернет, как бы не увеличивалась полоса пропускания на компьютерах пользователей.
Это особенно важно в связи с ростом популярности JavaScript-приложений, которые обычно содержат только разметку <script> и <link> рядом с пустым полем <body>. Так называемые одностраничные приложения (Single Page Applications, SPA) — сервер возвращает одну страницу, а всё остальное вызывается кодом на клиентской стороне.
Представьте сценарий, когда пользователь напрямую заходит по адресу аpp.com/orders. К моменту, когда ваше приложение получает и обрабатывает этот запрос, у него уже есть важная информация о том, что нужно показывать на странице. Оно может, например, подгрузить заказ из базы данных и добавить его в ответ. А вот большинство SPA в такой ситуации возвращает пустую страницу и тег <script>. Потом придётся ещё раз обменяться запросами для получения содержимого скрипта, и ещё раз — для получения контента.
Анализ HTML, отправляемого сервером для каждой страницы SPA
Многие разработчики сознательно идут на такую жертву. Они стараются гарантировать, что дополнительные сетевые хопы для пользователя произойдут только один раз, отправляя правильные заголовки для кеширования в ответах со скриптами и CSS. Общепринятое мнение состоит в том, что это приемлемая сделка, потому что после загрузки всех файлов на компьютер большинство действий пользователя (как переходы в другие разделы) осуществляются без запросов дополнительных страниц или скриптов.
Однако, даже с учётом кеша, имеется определённый проигрыш в производительности, если учесть время на парсинг и выполнение скрипта. В статье «jQuery слишком большой для мобильника?» говорится, как один только jQuery может тормозить некоторые мобильные браузеры на сотни миллисекунд.
Что ещё хуже, обычно пользователь не получает никакого фидбека в то время, как загружаются скрипты. Результат — чистая страница на экране, которая потом внезапно превращается в полностью загруженную страницу.
Самое главное, мы обычно забываем, что наиболее распространённые транспорт для передачи интернет-данных (TCP) стартует медленно. Это почти наверняка гарантирует, что большинство комплектов со скриптами не будут переданы за один раз, делая вышеописанную ситуацию ещё хуже.
TCP-соединение начинается с обмена пакетами для рукопожатия. Если вы используете SSL, что важно для безопасной передачи скриптов, происходит два дополнительных обмена пакетами (один, если клиент восстанавливает сессию). Только после этого сервер может начать отправку данных, но практика показывает, что он делает это медленно и порционно.
Механизм контроля заторов под названием Slow Start встроен в протокол TCP, чтобы отправлять данные, постепенно наращивая количество сегментов. Это имеет два серьёзных вывода для SPA:
1. Большие скрипты загружаются гораздо дольше, чем кажется. Как объясняется в книге «High Performance Browser Networking» Ильи Григорика, требуется «четыре обмена пакетами (…) и сотни миллисекунд задержки, чтобы выйти на 64 КБ обмена данными между клиентом и сервером». Например, в случае быстрого интернет-соединения между Лондоном и Нью-Йорком, требуется 225 мс, прежде чем TCP сможет выйти на максимальный размер пакета.
2. Поскольку это правило действует также для первоначальной загрузки страницы, то очень важно, какой контент грузится для рендеринга на странице в первую очередь. Как заключает Пол Ириш в своей презентации «Доставка товаров», критически важны первые 14 КБ
Сколько КБ сервер может отправить на каждом этапе соединения, по сегментам
Веб-сайты, которым удаётся доставить контент (пусть даже базовую разметку без данных) в этом окне, кажутся исключительно отзывчивыми. На самом деле, многие авторы быстрых серверных приложений воспринимают JavaScript как нечто ненужное или что нужно использовать с большой осторожностью. Такое отношение ещё больше усиливается, если у приложения быстрые бэкенд и база данных, а его серверы находятся возле пользователей (CDN).
Роль сервера в ускорении представления контента напрямую зависит от веб-приложения. Решение не всегда сводится к «рендерингу целых страниц на сервере».
В некоторых случаях, неактуальную в данный момент для пользователя часть страницы лучше исключить из первоначального ответа и оставить на потом. Некоторые приложения, например, предпочитают осуществить рендеринг только «ядра» страницы для обеспечения немедленного отклика. Затем они запрашивают разные части страницы параллельно. Это обеспечивает лучшую отзывчивость даже в ситуации с медленным устаревшим бэкендом. Для некоторых страниц хорошим вариантом будет рендеринг только видимой части страницы.
Исключительно важна качественная оценка скриптов и стилей с учётом информации, которая у сервера есть о сессии, клиенте и URL. Скрипты, которые осуществляют сортировку заказов, очевидно будут важнее для
Хороший пример SPA, которое не приводит к излишнему обмену пакетами, — концептуальный клон StackOverflow в 4096 байтах, он теоретически может загружаться с первым же пакетом после рукопожатия на TCP-соединении! Автор умудрился добиться такого за счёт отказа от кеширования, используя inline для всех ресурсов в ответе с сервера. Применив SPDY или HTTP/2 server push, теоретически возможно передать весь кешируемый клиентский код за один хоп. Ну а в настоящее время, рендеринг частей или всей страницы на стороне сервера остаётся самым популярным способом избавиться от лишних раундов обмена пакетами.
Proof-of-concept SPA с использованием inline для CSS и JS, чтобы избавиться от лишних roundtrip’ов
Достаточно гибкая система, которая разделяет рендеринг между браузером и сервером и предоставляет инструменты для постепенной загрузки скриптов и стилей, вполне может стереть грань между веб-сайтами и веб-приложениями. И то, и другое использует URL’ы, навигацию, демонстрирует данные пользователю. Даже приложение с электронными таблицами, которое традиционно полагается на функциональность с клиентской стороны, сначала должно показать клиенту информацию, которую требуется редактировать. И сделать это за наименьшее количество roundtrip’ов первостепенно важно.
С моей точки зрения, самый большой недостаток производительности во многих популярных системах в наше время объясняется прогрессивным накоплением сложности в стеке. Со временем добавлялись технологии вроде JavaScript и CSS. Их популярность тоже постепенно росла. Только сейчас мы можем оценить, как их можно использовать по-другому. Речь идёт и об улучшении протоколов (это показывает нынешний прогресс SPDY и QUIC), но наибольшую выгоду несёт всё-таки оптимизация приложений.
Полезно будет вспомнить некоторые исторические дискуссии вокруг дизайна ранних версий HTML и WWW. Например, этот список рассылки от 1997 года предлагает добавить тег <img> в HTML. Марк Андрессен повторяет, насколько важно быстро доставлять информацию:
«Если документ нужно составлять в единое целое на лету, то это может быть сколь угодно сложным, и даже если сложность ограничить, у нас всё равно возникнут крупные проблемы с производительностью из-за структуризации документов подобным способом. Прежде всего, это сразу нарушает принцип одного хопа в WWW (ну, IMG тоже его нарушает, но по очень специфической причине и в очень ограниченном смысле) — уверены ли мы, что хотим этого?»
2. Немедленный ответ на действия пользователя
tl;DR: JavaScript позволяет вообще спрятать сетевую задержку. Используя это как принцип дизайна, мы можем даже убрать из приложения почти все индикаторы загрузки и сообщения “loading”. PJAX или TurboLinks упускают возможности по увеличению субъективной скорости интерфейса.
Наша задача состоит в максимальном ускорении реакции на действия пользователя. Сколько бы усилий мы не вкладывали в уменьшение числа хопов при работе с веб-приложением, но есть вещи вне нашего контроля. Это теоретический предел скорости света и минимальный пинг между клиентом и сервером.
Важный фактор — непредсказуемое качество связи между клиентом и сервером. Если качество связи плохое, то будет происходить повторная передача пакетов. Там, где контент должен загружаться за пару roundtrip’ов, может понадобиться гораздо больше.
В этом главное преимущество JavaScript для улучшения UX. Если на клиентской стороне интерфейс управляется с помощью скриптов, мы можем спрятать сетевую задержку. Мы можем создать впечатление высокой скорости. Мы можем искусственно достигнуть нулевой задержки.
Предположим снова, что перед нами обычный HTML. Документы соединяются гиперссылками или тегами <a>. Если нажать на любой из них, то браузер осуществит сетевой запрос, что занимает непредсказуемо долгое время, потом получает и обрабатывает полученные данные и наконец переходит в новое состояние.
JavaScript позволяет реагировать немедленно и оптимистично на действия пользователя. Нажатие на ссылку или кнопку приводит к немедленной реакции, без обращения в Сеть. Известный пример — это интерфейс Gmail (или Google Inbox), в котором архивация почтового сообщения происходит немедленно, тогда как соответствующий запрос к серверу отправляется и обрабатывается асинхронно.
В случае с формой, вместо ожидания какого-то кода HTML в качестве ответа на её заполнение, мы можем реагировать сразу, как только пользователь нажал “Enter”. Или даже лучше, как делает поиск Google, мы можем реагировать ещё раньше, готовя разметку для новой страницы заблаговременно.
Такое поведение — пример того, что я называю
Заглавная страница Google вполне подходит в качестве примера, потому что она очень чётко демонстрирует первые два принципа из нашей статьи.
Во-первых, пакетный дамп TCP-соединения с www.google.com показывает, что они специально стараются отправить всю страницу целиком сразу после получения запроса. Весь обмен пакетами, включая закрытие соединения, занимает 64 мс для меня в Сан-Франциско. Вероятно, это было актуально для них с самого начала.
В конце 2004 года, компания Google стала пионером в использовании JavaScript для выдачи подсказок в реальном времени в процессе набора поискового запроса (интересно, что эту функцию сотрудник разработал в свободные от основной работы 20% времени, так же как и Gmail). Это даже стало фундаментом для появления Ajax:
Посмотрите на Google Suggest. Наблюдайте, как обновляются поисковые термины по мере набора текста, практически мгновенно… без задержки на перезагрузку страницы. Google Suggest и Google Maps — это два примера нового подхода к созданию веб-приложений, которые мы в Adaptive Path назвали “Ajax”
И в 2010 они представили Instant Search, в котором JS играет центральную роль, вообще исключая обновление страницы вручную и переключаясь на разметку «поисковые результаты» при первом же нажатии клавиши, как видно на иллюстрации вверху.
Другой видный пример адаптации разметки, возможно, лежит у вас в кармане. С первых же дней iPhone OS требовала от авторов приложений предоставить картинку default.png, которое можно сразу вывести на экран во время загрузки самого приложения.
iPhone OS принудительно загружает default.png перед запуском приложения
В этом случае операционная система компенсирует не сетевую задержку, а CPU. Это было важно, учитывая производительность раннего оборудования. Правда, в некоторых случаях такой подход давал сбой. Например, если картинка не соответствовала экрану ввода пароля. Подробный анализ результатов публиковал Марко Армент в 2010 году.
Другим типом действий, кроме кликов и отправки форм, которые отлично улучшаются с помощью JavaScript, является рендеринг загрузки файла.
Мы можем зарегистрировать попытку пользователя загрузить файл разными способами: drag-n-drop, вставка из буфера, выбор файла. Затем, благодаря новым HTML5 APIs, мы можем отобразить контент, как будто он уже загружен. Пример такого рода интерфейса — наша работа с загрузками в Cloudup. Обратите внимание, как миниатюра изображения генерируется и рендерится мгновенно:
Изображение рендерится и отображается до окончания загрузки
Во всех этих случаях мы улучшаем восприятие скорости. К счастью, существует много доказательств полезности такого подхода. Взять хотя бы пример, как увеличение расстояния до багажного конвейера в Хьюстонском аэропорту уменьшило количество жалоб на потерянный багаж, без необходимости ускорять обработку багажа.
Эта идея должна серьёзно повлиять на UI наших приложений. Я считаю, что индикаторы загрузки должны стать редкостью, особенно если мы переходим на приложения с информацией в реальном времени, которые описываются в следующем разделе.
Есть ситуации, когда иллюзия мгновенного действия в реальности оказывает вредный эффект на UX. Это может быть форма платежа или окончания сессии на сайте. Применяя здесь оптимистичный подход, де-факто обманывая пользователя, мы рискуем вызвать у него раздражение.
Но даже в этих случаях, отображение на экране спиннеров или индикаторов загрузки следует прекратить. Их нужно отображать только после того, как пользователь считатиает отклик не мгновенным. В соответствии с часто цитируемым исследованием Nielsen:
Базовый совет по времени отклика остаётся неизменным уже тридцать лет Miller 1968; Card et al. 1991:
* 0,1 секундs является лимитом, чтобы пользователь воспринимал отклик как немедленный, здесь не требуется отображение никакой дополнительной информации, кроме результата операции.
* 1,0 секунды является лимитом на непрерывность потока мысли у пользователя, даже хотя он заметит задержку. Обычно, не требуется никакой дополнительной индикации при задержки более 0,1 секунды, но менее 1,0 секунды, но у пользователя пропадает ощущение прямой работы с данными.
* 10 секунд является лимитом удерживания внимания пользователя на диалоге. При большей задержке пользователи захотят выполнить другую задачу, ожидая отклика от компьютера.
Техники вроде PJAX или TurboLinks, к сожалению, упускают большинство возможностей, описанных в данном разделе. Код на клиентской стороне не «знает» о будущем состоянии страницы до тех пор, пока не состоится обмен данными с сервером.
3. Реакция на изменение данных
tl;DR: Когда на сервере обновляются данные, клиента следует уведомлять без задержки. Это такая форма повышения производительности, когда пользователя освобождают от необходимости совершать дополнительные действия (нажимать F5, обновлять страницу). Новые проблемы: управление (повторным) соединением, восстановление состояния.
Третий принцип относится к реагированию UI на изменение данных в источнике, обычно, в одном или нескольких серверах баз данных.
Уходит в прошлое модель передачи по HTML данных, которые остаются статичными до тех пор, пока пользователь не обновит страницу (традиционные веб-сайты) или не взаимодействует с ней (Ajax).
Ваш UI должен обновляться автоматически.
Это критически важно в мире с нарастающим потоком информации из разных источников, включая часы, телефоны, планшеты и носимые устройства, которые появятся в будущем.
Представьте новостную ленту Facebook сразу после её появления, когда информацию публиковали, в основном, с персональных компьютеров пользователей. Статичный рендеринг нельзя было назвать оптимальным, но он имел смысл для людей, которые обновляли ленту, скажем, раз в день.
Сейчас мы живём в мире, когда ты загружаешь фотографию — и почти немедленно получаешь лайки и комментарии от друзей и знакомых. Необходимость в мгновенном отклике стала естественной необходимостью в конкурентном окружении других приложений.
Было бы неверным, однако, предположить, что преимущества мгновенного обновления UI ограничиваются только многопользовательскими приложениями. Вот почему я люблю говорить о согласованных дата-поинтах, вместо пользователей. Возьмём типичный сценарий синхронизации фотографии между телефоном и ваши собственным ноутбуком:
Однопользовательское приложение тоже может получить пользу от «реактивности»
Полезно представлять всю информацию, которая отправляется пользователю как «реактивную». Синхронизация сессии и состояния авторизации — один из примеров универсального подхода. Если у пользователей вашего приложения одновременно открыто несколько вкладок, то окончание рабочей сессии на одной из них должно сразу деактивировать авторизацию на всех остальных. Это неизбежно ведёт к улучшению безопасности и лучшей защите конфиденциальной информации, особенно в ситуациях, когда несколько человек имеют доступ к одному устройству.
Каждая страница реагирует на состоянии сессии и статус авторизации
Как только вы установили правило, что информация на экране обновляется автоматически, важно поработать над новой задачей: восстановление состояния.
При отправке запросов и получении атомарных обновлений легко забыть, что ваше приложение должно нормально обновляться даже после долгого отсутствия связи. Представьте, что вы закрываете крышку ноутбука и открываете её через несколько дней. Как будет вести себя приложение?
Пример того, что происходит в случае некорректного обновления связи
Способность приложения нормально восстанавливать связь взаимодействует с принципом № 1. Если вы выбрали отправлять данные при первой же загрузке страницы, вы должны учитывать и время, которое прошло перед загрузкой скриптов. Это время, по существу, эквивалентно времени дисконнекта, так что первоначальное подключение ваших скриптов является возобновлением сессии.
4. Контроль обмена данными с сервером
tl;DR: Теперь мы можем тонко настраивать обмен данными с сервером. Убедитесь в обработке ошибок, повторных запросах в пользу клиента, синхронизации данных в фоновом режиме и сохранении кеша в офлайне.
Когда появился веб, обмен данными между клиентом и сервером был ограничен несколькими способами:
- Нажатие на ссылку отправит
GETдля получения новой страницы и её рендеринга. - Отправка формы отправит POST или GET с последующим рендерингом новой страницы.
- Внедрение изображения или объекта отправит GET асинхронно с последующим рендерингом.
Простота такой модели очень привлекательна, и сейчас всё определённо усложнилось, когда речь идёт о понимании, как получать и отправлять информацию.
Главные ограничения касаются второго пункта. Невозможность отправить данные без обязательной загрузки новой страницы было недостатком с точки зрения производительности. Но самое главное, что это полностью ломало кнопку «Назад»:
Вероятно, самый раздражающий артефакт старого веба
Именно поэтому веб как платформа для приложений оставался неполноценным без JavaScript. Ajax представлял собой огромный скачок вперед с точки зрения удобства в части публикации информации пользователем.
Сейчас у нас есть множество API (XMLHttpRequest, WebSocket, EventSource, это лишь некоторые из них), которые дают полный и чёткий контроль над потоком данных. Кроме возможности публиковать пользовательские данные через форму, у нас появились новые возможности по улучшению UX.
Прямое отношение к предыдущему принципу имеет показ состояния соединения. Если мы ожидаем, что данные будут обновляться автоматически, то обязаны информировать пользователя о фактах потери связи и попытках её восстановления.
При обнаружении дисконнекта, полезно сохранить данные в памяти (а ещё лучше, в localStorage), так что их можно отправить позднее. Это особенно важно в свете будущего использования ServiceWorker, который позволяет приложениям JavaScript работать в фоновом режиме. Если ваше приложение не открыто, вы всё ещё можете продолжать попытки синхронизировать данные с сервером в фоновом режиме.
Учитывайте возможность таймаутов и ошибок при отправке данных, такие ситуации должны решаться в пользу клиента. Если соединение восстановлено, пробуйте отправить данные снова. В случае постоянной ошибки, сообщите об этом пользователю.
Некоторые ошибки нужно обрабатывать особенно внимательно. Например, неожиданная 403 может означать, что пользовательская сессия признана недействительной. В таких случаях, есть возможность восстановить сеанс, если показать пользователю окно для ввода логина и пароля.
Важно ещё убедиться, что пользователь случайно не прервёт поток данных. Это может случиться в двух ситуациях. Первый и самый очевидный случай — закрытие браузера или вкладки, что мы пытаемся предотвратить обработчиком beforeunload.
Предупреждение beforeunload
Другой (и менее очевидный) случай — попытка перехода на другую страницу, например, нажатие на ссылку. В этом случае приложение может остановить юзера иными методами, на усмотрение разработчика.
5. Не ломай историю, улучшай её
tl;DR: Если браузер не будет управлять URL’ами и историей, у нас возникнут новые проблемы. Убедитесь, что вы соответствуете ожидаемому поведению в отношении прокрутки. Сохраняйте собственный кеш для быстрого фидбека.
Если не считать отправки форм, то при использовании в веб-приложении одних только гиперссылок у нас будет полностью функциональная навигация «Вперёд/Назад» в браузере.
К примеру, типичную «бесконечную» страницу обычно делают с помощью кнопки на JavaScript, которая запрашивает дополнительные данные/HTML и вставляет их. К сожалению, немногие при этом помнят о необходимости вызова history.pushState или replaceState как обязательного шага.
Вот почему я использую слово «ломать». С простой моделью первоначального веба такая ситуация была невозможна. Каждое изменение состояния основывалось на изменении URL.
Но есть и обратная сторона медали — возможность улучшать историю сёрфинга, которую мы теперь контролируем средствами JavaScript.
Одну такую возможность Дэниел Пипиус назвал Fast Back:
Кнопка «Назад» должна работать быстро; пользователи не ожидают слишком большого изменения данных.
Это как рассматривать кнопку «Назад» в качестве кнопки из веб-приложения и применить к ней принцип № 2: немедленно реагировать на действие пользователя. Главное, что у вас есть возможность решить, как организовать кеширование предыдущей страницы и мгновенно вывести её на экран. Вы можете затем применить принцип № 3, а потом информировать пользователя о поступлении новых данных на эту страницу.
Всё ещё остаётся несколько ситуаций, когда вы не можете контролировать поведение кеша. Например, если вы отрендерили страницу, затем ушли на сторонний сайт, а потом пользователь нажал «Назад». Этому маленькому багу особенно подвержены приложения, которые рендерят HTML на стороне сервера, а потом модифицируют его на стороне клиента:
Некорректная работа кнопки «Назад»
Ещё один способ сломать навигацию — игнорирование памяти о состоянии прокрутки. Ещё раз, страницы, которые не используют JS и ручное управление историей, скорее всего, не будут иметь тут проблем. Но динамические страницы будут. Я протестировал две самые популярные новостные ленты на основе JavaScript в интернете: Twitter и Facebook. У обоих обнаружилась амнезия на прокрутку.
Бесконечное листание страниц — обычно, признак скроллинг-амнезии
В конце концов, опасайтесь таких изменений состояния, которые релевантны только при просмотре истории. Например, этот случай с изменением состояния поддеревьев с комментариями.
Изменение вида комментариев нужно сохранять в истории
Если страница была заново отрисована после нажатия ссылки внутри приложения, пользователь может ожидать, что все комментарии будут развёрнуты. При изменении состояния его нужно сохранить в истории.
6. Обновление кода через push-сообщения
tl;DR: Недостаточно отправлять через push-сообщения только данные, нужно ещё и код. Избегайте ошибок API и повышайте производительность. Используйте stateless DOM для безболезненной перелицовки приложения.
Исключительно важно, чтобы ваше приложение реагировало на изменения в коде.
Во-первых, это уменьшает количество возможных ошибок и повышает надёжность. Если вы сделали важное изменение в API бэкенда, то должны обновить код клиентских программ. В противном случае, клиенты могут не воспринять новые данные или могут прислать данные в несовместимом формате.
Не менее важной причиной является соблюдение принципа № 3. Если ваш интерфейс обновляется сам, то у пользователей мало причин обращаться к ручной перезагрузке страницы.
Имейте в виду, что у обычного сайта обновление страницы инициирует две вещи: перезагрузка данных и перезагрузка кода. Организация системы с push-обновлениями данных без push-обновлений кода неполноценна, особенно в мире, где одна вкладка (сессия) может оставаться открытой очень долгое время.
Если серверный push-канал работает, то пользователю можно выслать уведомление о доступности нового кода. Если нет, то номер версии можно добавить в заголовок исходящих HTTP-запросов. Сервер может сравнить его с последней известной версией, согласиться на обработку запроса или нет, и выдать задание для клиента.
После этого некоторые веб-приложения принудительно перезагружают страницу от имени пользователя. Например, если страница не находится в видимой области экрана и на ней нет заполненных форм для ввода.
Ещё лучший подход — «горячая» замена кода. Это значит, что не придётся осуществлять полную перезагрузку страницы. Вместо этого, определённые модули заменяются на лету, а их код повторно отправляется на выполнение.
Во многих существующих приложениях довольно сложно осуществить «горячую» замену кода. Для этого нужно изначально придерживаться архитектуры, которая разделяет поведение (код) от данных (состояние). Такое разделение позволит нам довольно быстро накатывать много разных патчей.
Например, в нашем веб-приложении есть модуль, который устанавливает шину для передачи event’ов (как socket.io). Когда событие наступает, состояние определённого компонента меняется и это отражается в DOM. Затем вы изменяете поведение этого компонента, например, так, что он генерирует разные разметки DOM для существующего и нового состояний.
В идеале у нас должна быть возможность менять код помодульно. Не нужно будет заново устанавливать соединение с сокетом, например, если есть возможность просто обновить код нужного компонента. Идеальная архитектура для push-обновлений кода, таким образом, является модульной.
Но сразу возникает проблема с тем, как оценить модули без нежелательных побочных эффектов. Здесь лучше всего подходит архитектура вроде той, которую предлагает React. Если код компонента обновляется, его логика может быть просто повторно исполнена, и DOM обновляется. Объяснение этой концепции от Дэна Абрамова читай здесь.
По существу, идея заключается в том, что вы обновляете DOM (или перекрашиваете его), что существенно помогает в замене кода. Если состояние сохранено в DOM или обработчики event’ов установлены приложением, то обновление кода может стать намного более сложной задачей.
7. Предсказание поведения
tl;DR: Отрицательная задержка.
У современного JavaScript-приложения могут быть механизмы для предсказания действий пользователя.
Наиболее очевидным применением этой идеи является заблаговременное скачивание данных с сервера, прежде чем пользователь их запросил. Скачивать веб-страницу, когда над ней появился курсор мыши, так что по нажатию на ссылки она отображается мгновенно, — это простой пример.
Немного более продвинутый метод мониторинга отслеживания движения мыши анализирует её траекторию на предмет будущего «столкновения» с интерактивными элементами, как кнопки. Пример на jQuery:
Плагин jQuery предугадывает траекторию мыши
Заключение
Веб остаётся самой многогранной средой передачи информации. Мы продолжаем добавлять динамику на наши страницы и перед их внедрением должны убедиться, что сохраним важные принципы веба, доставшиеся нам в наследство.
Страницы, связанные между собой гиперссылками, — хорошие строительные блоки для любого приложения. Поступательная загрузка кода, стилей и разметки по мере действий пользователя гарантирует отличную производительность без отказа от интерактивности.
Новые уникальные возможности предоставляет JavaScript. Если эти технологии будут повсеместно использоваться, то обеспечат наилучший опыт работы для пользователей самой свободной платформы из существующих — WWW.
Всем привет!
Сегодня мы с вами будем знакомиться с инструментом для создания веб-приложений для Windows и Windows Phone – Web Application Template.
В этой статье мы с вами разберемся, что такое веб-приложения и зачем они нужны, а также посмотрим, как Web Application Template может помочь вам при создании веб-приложений.
Зачем нужны веб-приложения, если есть веб-сайты
Если вы следите за развитием веб-технологий, то вы легко могли заметить, что граница между веб-сайтами и (нативными) приложениями постепенно стирается. Причем дело не только в технологической возможности использовать веб-стек для разработки нативных приложений (например, под Windows 8.x и Windows Phone 8.1 или Firefox OS), но и в целом с точки зрения UX (например, недавний анонс альфа-версии следующей версии Яндекс.Браузера явно движется в этом направлении).
Попытки использовать веб-стек для разработки приложений имеют уже давнюю историю: вспомнить хотя бы HTA для Windows. Аналогично время от времени предпринимаются и попытки «превратить» сайты в приложения, причем не только с точки зрения внутреннего наполнения (к примеру, outlook.com – это фактически почтовое приложение, а веб-версия Microsoft Office действительно позволяет редактировать и просматривать офисные документы), но и с точки зрения интеграции таких сайтов в операционную систему под видом приложений (тут достаточно вспомнить идею закрепленных сайтов в Internet Explorer, хотя это не единственный заход к этой идее в индустрии). С развитием магазинов приложений эти идеи приобретают новые черты, как маркетингового характера (а что, если мы будем распространять сайт через магазин приложений), так и технического, особенно в случае платформ без нативной поддержки HTML/JS (обычно решается через WebView или аналоги и обвязки над ними).
Сегодня за стремлением превратить веб-сайт в (нативное) веб-приложение стоит множество возможностей по расширению взаимодействия с людьми по ту сторону сенсорных экранчиков:
- (Контролируемый) доступ к различным функциям устройства и операционной системы, которые обычно спрятаны за песочницой браузера, не имеют еще аналога в виде соответствующего веб-стандарта или просто не поддерживаются браузером посетителя сайта. Например, вы можете получить доступ к адресной книге пользователя или камере.
- Веб-сайту, как правило, нужен постоянный доступ к интернету (удобство использования AppCache – это тема для отдельного разговора). В случае приложения, разработчику доступна гибкая настройка работы приложения в оффлайн режиме – можно заранее закэшировать необходимые ресурсы, в том числе в фоне.
- Вы можете интегрировать в веб-приложение элементы управления системы, под которую вы делаете приложение, мимикрируя таким образом под привычное окружение.
- Еще один плюс в копилку веб-приложений – поддержка push-уведомлений. Push уведомления являются дополнительной возможностью взаимодействия с пользователем. Расскажите им об акциях вашего интернет-магазина или обновите информацию о новых сообщениях на плитке телефона!
И это лишь первое, что приходит в голову, а ведь есть же еще механизмы монетизации, интеграция с внешними устройствами и много чего еще.
Таким образом, при помощи веб-приложения можно расширить возможности вашего веб-сайта, сделать его более интерактивным и интегрировать в него различные дополнительные, ранее недоступные, функции.
В принципе, в том, чтобы самостоятельно обернуть своей веб-сайт в приложение, нет ничего сложного. Берете Webview – и оборачиваете.
Дьявол, однако, как всегда зарыт в деталях, поэтому мы сделали готовый движок для таких задач. Движок называется WAT (хотя в названии есть слово template, там реально целый движок!). Кстати, с открытым кодом.
Шаблон для создания веб-приложений – Web App Template
Web Application Template (WAT) — шаблон для Visual Studio для создания универсальных приложений для Windows и Windows Phone на базе веб-сайта.
Для работы вам понадобятся:
- Ваш сайт (в идеале, с адаптивной версткой)
- Windows 8.1
- Visual Studio 2013+
- Расширение WAT
Установка дополнения Web App Template
Для того, чтобы установить WAT, вам необходима Windows 8.1 и Microsoft Visual Studio с последними обновлениями. Загрузите установочный VSIX файл с сайта wat.codeplex.com и установите шаблон.
Создание проекта Web Application Template
Создайте проект Web App Template, он будет находиться по пути: File> New > Project > Templates > JavaScript > Web App Template for Universal Apps
Будет создано универсальное приложение для Windows и Windows Phone, состоящее из пяти проектов – проект Windows, проект Windows Phone, общие файлы для проектов Windows и Windows Phone, а также внутренние C#-проекты.
Если сейчас запустить проекты для Windows и Windows Phone, то запустится приложение и загрузится страница с документацией по шаблону Web App Template.
Давайте посмотрим на структуру проектов Windows и Windows Phone и проекта с общими файлами (Shared), а также разберемся с настройками шаблона.
В проекте приложения находится большое количество различных файлов. Мы рассмотрим те, в которых определяются основные настройки Web App Template.
Файлы, находящиеся в проекте Windows и Windows Phone, идентичны, в основном они относятся к общим настройкам приложения для конкретной платформы. Обратите внимание на файл package.appxmanifest – файл манифеста приложения, который нужен при подготовке приложения к публикации. В нем указываются основные настройки вашего приложения, информация о необходимых для его работы функциях, устройствах, а также файлах картинок (для иконок, бейджев, тайлов). Подробно о нем можно узнать в MVA курсе «Размещение и продвижение приложений в Windows Store.
Давайте перейдем к проекту с общими файлами. Первая папка в нем – папка config, с файлами config.es.json, config.json, config.sample.json и files.json.
config.json – главный файл приложения. Он используется для добавления основных настроек приложения – определения веб-сайта приложения (главной страницы), добавления элементов управления (панелей управления, навигации, кнопки назад), поддержки оффлайн режима, уведомлений и т.д.
Файл config.es.json отвечает за локализацию приложения, в нем прописаны основные языковые настройки (перевод фраз, подсказок). В стандартном шаблоне в качестве примера находится файл для языковых настроек испанского языка. Вы можете создавать файлы локализации для каждого поддерживаемого языка, он будет применяться в приложении автоматически. В файле config.sample.json находятся примеры всех настроек, которые вы можете применить в вашем приложении.
Следующая папка, CSS – папка с файлами, определяющими стиль вашего приложения. Injected-styles.css отвечает за CSS стили сайта, для которого вы делаете приложение, а файл wrapper-styles.css используется для стилизации таких объектов приложения, как navbar и appbar и т.д.
В папке template находятся JavaScript файлы реализации WAT, например, обработка геолокации, уведомлений, оффлайн режима, поиска и т.д.
Если уже использовали WAT ранее, обратите внимание на папки, которые добавились в WAT версии 2.2:
- Папка schema в проекте с общими файлами. В ней содержится файл schema-manifest.json. Это файл схемы для файла config.json. В нем описывается каждая функция, ее тип, описание и значение по умолчанию.
- Папка strings. Там находятся папки с доступными локализациями, т.е. файлы, в которых мы указываем перевод стандартных фраз в приложении.
Также обратите внимание на возможность удаленного редактирования файла config.json. Для того, чтобы заменить файл, в панели настроек выберите пункт «Change Config Host Address»
Затем введите адрес нового config файла:
В таблице, расположенной ниже, представлено описание всех основных файлов проекта. Мы же перейдем к знакомству с файлом config.json и посмотрим доступные для нашего приложения настройки.
Структура файла config.json
Все основные настройки для нашего шаблона находятся в файле config.json. Формат config.js базируется на стандарте W3C Application Manifest, добавляя в него расширения, специфичные для WAT.
В нем вы определяете главную страницу вашего приложения, навигацию по странице, настройки панели приложения и панели навигации панели чудо-кнопок, а также поддержку оффлайн режима и т.д.
Полную документацию по файлу config.json вы можете найти здесь — http://wat-docs.azurewebsites.net/, а ниже я приведу таблицу с частичным переводом документации:
Развернуть таблицу с документацией| Название блока настройки | Описание | Пример кода |
| start_url | Главная страница вашего приложения | |
| wat_errors | Определяет страницу с сообщением об ошибке | |
| wat_logging | Задает настройки логов приложения | |
| wat_offline | Определяет поведение приложения в оффлайн режиме | |
| wat_geoLocation | Включает/выключает поддержку геолокации | |
| wat_customScript | Массив скриптов, расположенных в пакете приложения, которые содержатся в DOM | |
| wat_appBar | Элемент управления, находящийся внизу страницы | |
| wat_navBar | Элемент управления, находящийся сверху страницы | |
| wat_livetile | Определяет уведомления, появляющиеся на плитках | |
| wat_redirects | Управляет внешними URL | |
| wat_settings | Определяет свойства чудо-кнопки «настройки» | |
| wat_share | Задает настройки чудо-кнопки «поделиться» | |
| wat_search | Определяет свойства чудо-кнопки «поиск» | |
| wat_secondaryPin | Задает настройки для плиток на рабочем столе | |
В качестве небольшого примера давайте стилизуем блок header. Напомню, блок header определяет свойства верхней части нашей страницы. Вы можете настроить его цвет, видимость заголовка страницы и отображение header’a в целом.
"wat_header": {
"enabled": true,
"backgroundColor": "#478EFF",
"navDrawerBackgroundColor": "#375569",
"logo": "/images/widelogo.scale-100.png",
"title": {
"enabled": true,
"displayOnHomePage": true
}
}
Как вы видите header добавился. Видно, что для Windows приложения этого сайта он выглядит симпатично, а для Windows Phone приложения header явно лишний.
Обратите внимание:
Чаще всего config.json находится в проекте с общими файлами (shared). Но, иногда, бывают случаи, когда мы разделяем файл config.json на два проекта – отдельно для проекта Windows и отдельно для проекта Windows Phone. К разделению файла по проектам мы прибегаем, например, в случае, если у нас есть специальная мобильная версия сайта, соответственно, стартовые страницы (startURL) для Windows и Windows Phone проекта будут разными. Иногда также удобно разделить файлы по проектам, когда в разных проектах нам необходимы разные элементы управления (приведенный выше пример с header).
Мы с вами разобрались с тем, что такое веб-приложения и как научиться создавать их при помощи шаблона Web App Template. В следующей статье мы посмотрим, как применить полученные знания и создать веб-приложение сайта Habrahabr.ru.
Дополнительные ссылки
Как работают веб-приложения / Хабр
Это статья для начинающих разработчиков и тех, кто хочет немного ориентироваться в терминах и технологиях современных веб-приложений. В статье написано о том, чем веб-приложения отличаются от сайтов, какие бывают веб-приложения, из чего они состоят и как работают.1. Чем веб-приложения отличаются от сайтов
Для меня сайт это в первую очередь что-то информационное и статичное: визитка компании, сайт рецептов, городской портал или вики. Набор подготовленных заранее HTML-файлов, которые лежат на удаленном сервере и отдаются браузеру по запросу.
Сайты содержат различную статику, которая как и HTML-файл не генерируется на лету. Чаще всего это картинки, CSS-файлы, JS-скрипты, но могут быть и любые другие файлы: mp3, mov, csv, pdf.
Блоги, визитки с формой для контакта, лендинги с кучей эффектов я тоже отношу для простоты к сайтам. Хотя в отличие от совсем статических сайтов, они уже включают в себя какую-то бизнес-логику.
А веб-приложение — это что-то технически более сложное. Тут HTML-страницы генерируются на лету в зависимости от запроса пользователя. Почтовые клиенты, соцсети, поисковики, интернет-магазины, онлайн-программы для бизнеса, это все веб-приложения.
2. Какие бывают веб-приложения
Веб-приложения можно разделить на несколько типов, в зависимости от разных сочетаний его основных составляющих:
- Backend (бэкенд или серверная часть приложения) работает на удаленном компьютере, который может находиться где угодно. Она может быть написана на разных языках программирования: PHP, Python, Ruby, C# и других. Если создавать приложение используя только серверную часть, то в результате любых переходов между разделами, отправок форм, обновления данных, сервером будет генерироваться новый HTML-файл и страница в браузере будет перезагружаться.
- Frontend (фронтенд или клиентская часть приложения) выполняется в браузере пользователя. Эта часть написана на языке программирования Javascript. Приложение может состоять только из клиентской части, если не требуется хранить данные пользователя дольше одной сессии. Это могут быть, например, фоторедакторы или простые игрушки.
- Single page application (SPA или одностраничное приложение). Более интересный вариант, когда используются и бэкенд и фронтенд. С помощью их взаимодействия можно создать приложение, которое будет работать совсем без перезагрузок страницы в браузере. Или в упрощенном варианте, когда переходы между разделами вызывают перезагрузки, но любые действия в разделе обходятся без них.
3. Pyhon-фреймворк Django aka бэкенд
В разработке фреймворк — это набор готовых библиотек и инструментов, которые помогают создавать веб-приложения. Для примера опишу принцип работы фреймворка Django, написанного на языке программирования Python.
Первым этапом запрос от пользователя попадает в роутер (URL dispatcher), который решает какую функцию для обработки запроса надо вызвать. Решение принимается на основе списка правил, состоящих из регулярного выражения и названия функции: если такой-то урл, то вот такая функция.
Функция, которая вызывается роутером, называется вью (view). Внутри может содержаться любая бизнес-логика, но чаще всего это одно из двух: либо из базы берутся данные, подготавливаются и возвращаются на фронт; либо пришел запрос с данными из какой-то формы, эти данные проверяются и сохраняются в базу.
Данные приложения хранятся в базе данных (БД). Чаще всего используются реляционные БД. Это когда есть таблицы с заранее заданными колонками и эти таблицы связаны между собой через одну из колонок.
Данные в БД можно создавать, читать, изменять и удалять. Иногда для обозначения этих действий можно встретить аббревиатуру CRUD (Create Read Update Delete). Для запроса к данным в БД используется специальный язык SQL (structured query language).
В Джанго для работы с БД используются модели (model). Они позволяют описывать таблицы и делать запросы на привычном разработчику питоне, что гораздо удобнее. За это удобство приходится платить: такие запросы медленнее и ограничены в возможностях по сравнению с использованием чистого SQL.
Полученные из БД данные подготавливаются во вью к отправке на фронт. Они могут быть подставлены в шаблон (template) и отправлены в виде HTML-файла. Но в случае одностраничного приложения это происходит всего один раз, когда генерируется HTML-страница, на который подключаются все JS-скрипты. В остальных случаях данные сериализуются и отправляются в JSON-формате.
4. Javascript-фреймворки aka фронтенд
Клиентская часть приложения — это скрипты, написанные на языке программирования Javascript (JS) и исполняемые в браузере пользователя. Раньше вся клиентская логика основывалась на использовании библиотеки JQuery, которая позволяет работать с DOM, анимацией на странице и делать AJAX запросы.
DOM (document object model) — это структура HTML-страницы. Работа с DOM — это поиск, добавление, изменение, перемещеие и удаление HTML-тегов.
AJAX (asynchronous javascript and XML) — это общее название для технологий, которые позволяют делать асинхронные (без перезагрузки страницы) запросы к серверу и обмениваться данными. Так как клиентская и серверная части веб-приложения написаны на разных языках программирования, то для обмена информацией необходимо преобразовывать структуры данных (например, списки и словари), в которых она хранится, в JSON-формат.
JSON (JavaScript Object Notation) — это универсальный формат для обмена данными между клиентом и сервером. Он представляет собой простую строку, которая может быть использована в любом языке программирования.
Сериализация — это преобразование списка или словаря в JSON-строку. Для примера:
Словарь:
{
'id': 1,
'email': '[email protected]'
}Сериализованная строка:
'{"id": 1, "email": "[email protected]"}'Десериализация — это обратное преобразование строки в список или словарь.
С помощью манипуляций с DOM можно полностью управлять содержимым страниц. С помощью AJAX можно обмениваться данными между клиентом и сервером. С этими технологиями уже можно создать SPA. Но при создании сложного приложения код фронтенда, основанного на JQuery, быстро становится запутанным и трудно поддерживаемым.
К счастью, на смену JQuery пришли Javascript-фреймворки: Backbone Marionette, Angular, React, Vue и другие. У них разная философия и синтаксис, но все они позволяют с гораздо большим удобством управлять данными на фронтенде, имеют шаблонизаторы и инструменты для создания навигации между страницами.
HTML-шаблон — это «умная» HTML-страница, в которой вместо конкретных значений используются переменные и доступны различные операторы: if, цикл for и другие. Процесс получения HTML-страницы из шаблона, когда подставляются переменные и применяются операторы, называется рендерингом шаблона.
Полученная в результате рендеринга страница показывается пользователю. Переход в другой раздел в SPA это применение другого шаблона. Если необходимо использовать в шаблоне другие данные, то они запрашиваются у сервера. Все отправки форм с данными это AJAX запросы на сервер.
5. Как клиент и сервер общаются между собой
Общение клиента с сервером происходит по протоколу HTTP. Основа этого протокола — это запрос от клиента к серверу и ответ сервера клиенту.
Для запросов обычно используют методы GET, если мы хотим получить данные, и POST, если мы хотим изменить данные. Еще в запросе указывается Host (домен сайта), тело запроса (если это POST-запрос) и много дополнительной технической информации.
Современные веб-приложения используют протокол HTTPS, расширенную версию HTTP с поддержкой шифрования SSL/TLS. Использование шифрованного канала передачи данных, независимо от важности этих данных, стало хорошим тоном в интернете.
Есть еще один запрос, который делается перед HTTP. Это DNS (domain name system) запроc. Он нужен для получения ip-адреса, к которому привязан запрашиваемый домен. Эта информация сохраняется в браузере и мы больше не тратим на это время.
Когда запрос от браузера доходит до сервера, он не сразу попадает в Джанго. Сначала его обрабатывает веб-сервер Nginx. Если запрашивается статический файл (например, картинка), то сам Nginx его отправляет в ответ клиенту. Если запрос не к статике, то Nginx должен проксировать (передать) его в Джанго.
К сожалению, он этого не умеет. Поэтому используется еще одна программа-прослойка — сервер приложений. Например для приложений на питоне, это могут быть uWSGI или Gunicorn. И вот уже они передают запрос в Джанго.
После того как Джанго обработал запрос, он возвращает ответ c HTML-страницей или данными, и код ответа. Если все хорошо, то код ответа — 200; если страница не найдена, то — 404; если произошла ошибка и сервер не смог обработать запрос, то — 500. Это самые часто встречающиеся коды.
6. Кэширование в веб-приложениях
Еще одна технология, с которой мы постоянно сталкиваемся, которая присутствует как веб-приложениях и программном обеспечении, так и на уровне процессора в наших компьютерах и смартфонах.
Cache — это концепция в разработке, когда часто используемые данные, вместо того чтобы их каждый раз доставать из БД, вычислять или подготавливать иным способом, сохраняются в быстро доступном месте. Несколько примеров использования кэша:
- В Джанго пришел запрос на получение данных для графика в отчете. Мы достаем из БД данные, подготавливаем их и кладем в БД с быстрым доступом, например, memcached на 1 час. При следующем запросе мы сразу достанем их из memcached и отправим на фронтенд. Если мы узнаём, что данные перестали быть актуальными, мы их инвалидируем (удаляем из кэша).
- Для кэширования статических файлов используются CDN (content delivery network) провайдеры. Это серверы, расположенные по всему миру и оптимизированные для раздачи статики. Иногда бывает эффективнее положить картинки, видео, JS-скрипты на CDN вместо своего сервера.
- Во всех браузерах по умолчанию включено кэширование статических файлов. Благодаря этому, открывая сайт не в первый раз, все загружается заметно быстрее. Минус для разработчика в том, что со включенным кэшем не всегда сразу видны изменения сделанные в коде.
На следующем этапе необходимо собрать требования к приложению, которое необходимо разработать. Уточнить цели и область решаемых задач и построить иерархическую структуру работ.
Рассмотрим отдельно задачу построения иерархической структуры работ. Каждое web-приложение можно представить в следующем виде:
Другими словами, каждое web-приложение отправляет http запросы на web-сервер для получения полезных данных. Программа под управлением web-сервера использует ту или иную модель для хранения данных. В современном мире чаще всего используются базы данных, SQL или NoSQL.
Формально каждое web-приложение можно разбить на 3 взаимно независимые части.
- Модуль, который исполняется WEB-браузером. Это приложение может быть написано на любом языке, который поддерживает браузер. Чаще всего используется язык JavaScript, как наиболее поддерживаемый и имеющий большую библиотечную поддержку. Это очень важно, так как позволяет существенно экономить бюджеты проектов.
- Модуль, исполняемый на серверной стороне под управлением web-сервера. Это приложение может быть написано на любом языке, интерпретацию которого поддерживает выбранный Вами web-сервер. Последнее время, часто, в качестве языка программирования выбирается язык Java. Этот язык также имеет серьезную библиотечную поддержку.
- База данных. В этой области так же существует достаточно широкий выбор. Есть промышленные базы данных, такие как Oracle, DB2, PostgreSQL. Есть легкие базы данных, такие как MySQL. База данных выбирается основываясь на целях и области решаемых задач.
Возможные эталонные модели проектирования web-приложений.
При построении архитектуры web — приложения необходимо максимально уменьшить зависимость между структурными единицами. В общем случае приложение состоит из трех структурных единиц.
- Модуль, который работает под управлением браузера.
- Модуль, который работает под управлением web-сервера.
- База данных.
Эти структурные единицы порождают два вида связей.
- Связь между браузером и серверной частью.
- Связь между серверной частью и базой данных.
Для достижения цели максимальной независимости между структурными единицами, необходимо чтобы каждая структурная единица оперировала только необходимым ей набором данных. Рассмотрим более подробно.
Браузер — это прикладное программное обеспечение для просмотра web страниц.
HTML – это стандартный язык разметки документов. Большинство современных web-браузеров способны интерпретировать язык HTML.
Web сервер — это программное обеспечение, которое способно принимать HTTP запросы от клиентов, обрабатывать их и отправлять ответ в соответствии со стандартом протокола.
База данных — это представленная в объективной форме совокупность самостоятельных материалов, систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью ЭВМ.(Wiki)
Минимизация зависимостей
Для минимизации зависимостей между «Браузером» и Web-сервером необходимо, чтобы язык разметки HTML был задействован только в браузере, а Web-сервер предоставлял интерфейс для получения необходимых данных для страницы.
Для решения этой задачи необходимо:
- Определить цели и область решаемых задач, которые будут решаться в рамках создаваемого интерфейса.
- Определить API серверной части.
- Выбрать протокол взаимодействия между серверной и клиентской частью. Создание протокола удобнее всего выбрать на базе XML, так как большинство современных браузеров имеют встроенную поддержку этого языка.
- Написать документ, в котором будет изложен протокол.
Наша диаграмма может быть преобразована в следующий вид:
Далее «Браузер» преобразуется в UML диаграммы состояний. На этих диаграммах будет отражено, в каком случае вызывается тот или иной метод.
Данная модель достижима двумя путями
- Программа выполняемая «Браузером» написана на JavaScript и общается с Web-Сервером через AJAX, получая ответы в соответствие с определенным протоколом.
- «Браузер» интерпретирует только HTML код, а преобразования происходят посредством XSLT преобразований на стороне Web-Сервера.
В каждом из этих случаев достигается разделение программной части Web-Сервера и «Браузера». Т.е используя данную модель возможно вносить изменения в структурную единицу для «Браузера» и не вызывать косвенных изменений в серверной части. Это очень важно, так как ведет к уменьшению затрат на обработку запросов на изменения. Это происходит в силу того, что изменения в одной структурной единицы не выходят за ее рамки.
Взаимодействие Web-Сервера и Базы данных
Взаимодействие базы данных и web-сервера возможно организовать на основании двух принципиально разных сценариях:
- Бизнес логика находится в базе данных.
- Бизнес логика находится в коде web-сервера.
В первом случае база данных хранит данные и предоставляет интерфейс доступа к данным:
- Выборка данных — решается через представления.
- Модификация данных — решается через хранимые процедуры.
Программа для web-сервера является драйвером для доступа к бизнес-логике. Т.е она просто связывает Браузер с бизнес логикой, которая реализована в базе данных.
Во втором случае база данных хранит данные, и предоставляет прямой доступ к данным. Бизнес-логика реализована в коде web-сервера. В этом случае база данных предоставляет транзакции для проведения атомарных операций.
Для минимизации зависимостей между Web-Сервером и Базой данных, необходимо, чтобы бизнес-логика была определена только в одном месте. Т.е либо в коде Web-Сервера, либо в Базе данных. Это очень важно, так как ведет к уменьшению затрат на обработку запросов на изменения. Это происходит в силу того, что изменения в одной структурной единицы не выходят за ее рамки.
Иерархическая структура работ
На основании изложенного выше материала иерархическая структура работ примет следующий вид:
- Модуль для «Браузера».
- Модуль для Web-Сервера.
- Модуль для Базы данных.
- Протокол обмена между модулем «Браузера» и Web-Сервером.
- Интерфейс взаимодействия между модулем «Браузера» и Web-Сервером.
- Интерфейс взаимодействия между Web-Сервером и Базой данных.
Превращение веб-сайта в мобильное приложение
Обзор
На рисунке выше показан код, который позволяет превратить веб-сайт в мобильное приложение. В частности, за «превращение» отвечают семь строк JSON, выделенные оранжевым цветом. Оставшиеся фрагменты текста программы описывают возможности, относящиеся к мобильной платформе, на которой выполняется приложение.
Что, если я скажу вам, что для того, чтобы воспользоваться этим подходом, не нужно переделывать сайт, пользуясь неким фреймворком, приближающим внешний вид ресурса к виду мобильного приложения? Более того, что если весь процесс разработки заключается в подключении сайта к мобильному приложению, подобному показанному выше, с помощью обычного URL?
Кроме того, вот ещё один вопрос: «Можно ли, просто редактируя JSON, работать с нативными API, с компонентами пользовательского интерфейса, пользоваться системными переходами между страницами?».
Пока вы размышляете над ответами на эти вопросы, предлагаю взглянуть на то, как выглядит и работает минимальное приложение, созданное с использованием инструментов, о которых я хочу здесь рассказать.
Минимальное приложение
Обратите внимание на то, как я встроил в это приложение страницу с github.com, однако всё остальное — это нативные компоненты, вроде верхней навигационной панели и нижней панели управления. При этом переходы между страницами приложения используют системные возможности. Делается это автоматически и не требует вмешательства в код сайта.
Прежде чем я расскажу о том, как это сделано, у вас может возникнуть вполне резонный вопрос: «Всё это хорошо, но можно ли, пользуясь методом, о котором идёт речь, создать что-то действительно полезное, а не нечто вроде простого «просмотрщика» веб-страниц в контейнере нативного приложения?».
Отличный вопрос. Собственно говоря, ответу на него и посвящена данная статья. Если в двух словах, то суть рассматриваемой здесь методики заключается в создании двустороннего канала связи между контейнером для вывода веб-содержимого и приложением. Приложению это даст возможность вызывать JavaScript-функции, находящиеся в контейнере, а контейнеру позволит обращаться к нативным API, расположенным за его пределами.
Взглянем на пример, иллюстрирующий вышесказанное.
Приложение для создания QR-кодов
Вот основные составные части этого приложения:
- Нативный навигационный заголовок, поддерживающий встроенные возможности переходов.
- Элемент WebView, в который встроено веб-приложение, генерирующее QR-коды.
- Системный компонент для ввода текстов в нижней части окна.
Описание всех этих элементов можно выполнить, просто приведя к соответствующему виду атрибуты JSON-разметки, подобной показанной выше.
И, наконец, обратите внимание на то, что тут показано и взаимодействие компонентов приложения. А именно, QR-код меняется после ввода новых данных. Делается это благодаря возможности вызова JavaScript-функции, расположенной внутри веб-приложения, которая отвечает за создание QR-кодов на основе переданных ей данных.
Надо отметить, что ни один из фреймворков для разработки мобильных приложений не пытался фундаментально решить проблему «прозрачной интеграции веб-контейнеров в нативные приложения», так как все они либо полностью ориентированы на системные возможности мобильных платформ, либо целиком полагаются на HTML5.
Когда говорят о будущем мобильных приложений, обычно всё крутится вокруг вопроса о том, какой из подходов победит: основанный на HTML5 или на нативных API. Что характерно, в подобных рассуждениях не поднимается тема сосуществования этих двух подходов, и, более того, не рассматривается эффект синергии, который, благодаря совместному использованию различных технологий, позволит достигать результатов, которые нелегко достигнуть, полагаясь лишь на что-то одно.
В этом материале я собираюсь рассказать о следующих вещах:
- О том, почему совместное использование веб-кода и нативных компонентов — это, нередко, хорошая идея.
- О том, почему прозрачная интеграция HTML и нативных компонентов — это непростая задача, и о том, как мне удалось её решить.
- И, что самое важное, я расскажу о том, как вы можете использовать технологии, о которых пойдёт речь, для быстрой разработки собственных приложений.
Зачем использовать веб-технологии в мобильных приложениях?
Прежде чем продолжать, давайте сначала поговорим о том, нормально ли это — использовать возможности HTML и JS в мобильных приложениях, и о том, когда может пригодиться подобный подход. Вот несколько ситуаций, когда смешивание веб-технологий с нативными возможностями мобильных платформ может оказаться кстати.
▍1. Использование технологий, созданных для веб
Для реализации некоторых частей приложений может иметь смысл использование веб-технологий. Например, WebSocket — это технология, изначально ориентированная на веб. Для её использования можно применить встроенный в мобильную платформу веб-движок (
WKWebView для iOS и WebView для Android) вместо установки сторонней библиотеки, которая попросту «эмулирует» WebSocket.При таком подходе не нужно использовать дополнительные библиотеки, достаточно, применяя стандартные технологии, делать то, что нужно. Это ведёт нас к следующей ситуации.
▍2. Уменьшение размеров пакета приложения
Использование веб-технологий в мобильных приложениях помогает делать то, что без этих технологий потребовало бы огромных сторонних библиотек.
Например, для того, чтобы встроить в мобильное приложение генератор QR-кодов, понадобится сторонняя библиотека, которая увеличит размер пакета приложения. Однако если применить для этого стандартное средство для просмотра веб-страниц и JS-библиотеку, подключённую к странице с помощью простой конструкции <script>, можно получить всё необходимое без установки сторонних библиотек.
▍3. Решение проблемы отсутствия надёжных мобильных библиотек
Для некоторых новейших технологий пока не созданы их надёжные и стабильные мобильные реализации. Однако, большинство этих технологий доступны в веб-среде. В результате самый эффективный способ их интеграции в мобильные приложения заключается в использовании соответствующей JavaScript-библиотеки.
▍4. Разработка проектов, использующих и возможности мобильных платформ, и веб-приложений
Многие начинающие разработчики, которые хотят превратить свои веб-сайты в мобильные приложения, оказываются в непростой ситуации, по ходу дела выясняя, что некоторые функции их веб-проектов слишком сложны для того, чтобы воссоздать их с нуля для каждой из целевых мобильных платформ.
Например, одна из страниц некоего сайта может оказаться слишком сложной для того, чтобы быстро конвертировать её в формат мобильного приложения, в то время как всё остальное наполнение сайта без проблем портируется в мобильное приложение.
В подобном случае было бы очень кстати, если бы большую часть приложения можно было бы создавать средствами мобильной платформы, но какую-то особенно сложную страницу можно было бы прозрачно интегрировать в приложение в её исходном виде.
Как это работает?
▍A. Jasonette
Jasonette — это опенсорсный проект, направленный на создание кросс-платформенных нативных приложений, основанных на JSON-разметке.
Фреймворк Jasonette похож на веб-браузер, но, вместо того, чтобы превращать HTML-код в веб-страницы, он преобразует JSON-разметку в нативные приложения для iOS и Android. Сходство с браузером заключается и в том, что любое приложение, основанное на Jasonette, имеет одинаковый базовый код, который занимается интерпретацией различных наборов JSON-данных в процессе формирования итогового приложения. Разработчику не нужно работать с кодом библиотеки. Процесс создания приложения заключается в подготовке его JSON-описания, которое позволяет Jasonette, в реальном времени, преобразовывать веб-страницы в нативные приложения.
Подробности о Jasonette можно почитать здесь. В целом, можно сказать, что проект Jasonette направлен на разработку нативных приложений, а здесь мы поговорим о том, как интегрировать HTML-страницы в эти нативные приложения.
▍B. Jasonette Web Container
Сами по себе нативные мобильные приложения — это прекрасно, но иногда в них хочется использовать веб-технологии, что можно сделать с помощью стандартных веб-контейнеров. Однако, их интеграция в приложения — дело непростое. Вот что нужно для прозрачной интеграции веб-технологий в нативные приложения:
- Веб-контейнер должен представлять собой естественную часть интерфейса мобильного приложения. Контейнер должен выглядеть так же, как любой другой компонент пользовательского интерфейса приложения. В противном случае получится нечто неуклюжее, выглядящее как то, чем оно является на самом деле — веб-сайтом, который показывают в мобильном приложении.
- Родительское приложение должно иметь возможность контролировать дочерний веб-контейнер. При таком подходе приложение, частью которого является элемент управления для просмотра содержимого веб-страницы, будет иметь удобные средства для воздействия на него.
- Дочерний веб-контейнер должен иметь возможность вызывать системные события в родительском приложении. У веб-контейнера, встроенного в приложение, должны быть средства для обращения к нативным API.
На самом деле, реализация всего этого требует немалых усилий, поэтому я начал с первого пункта этого списка — с простого встраивания веб-контейнера в страницы нативных приложений. Так я выпустил первую версию JSON Web Container.
Эта штука оказалась полезной, но ей не хватало возможностей по взаимодействию родительского приложения с веб-контейнером. А именно, родительское приложение не могло контролировать веб-контейнер, а контейнер не мог обращаться к родительскому приложению. Как результат, контейнер оказывался полностью изолированным от своего окружения в виде приложения.
▍C. Jasonette Web Container 2.0: взаимодействие приложения и контейнера
После выпуска первой версии, я экспериментировал со второй частью вышеописанной задачи, которая заключалась в том, чтобы позволить контейнеру взаимодействовать с родительским приложением.
Поговорим о том, как мне удалось добавить обычному веб-контейнеру интерактивности, что сделало его гораздо более мощным и интересным.
Реализация: интерактивный Web Container
▍1. Загрузка по URL
Задача
Ранее, в первой версии, для того, чтобы использовать веб-контейнер в виде компонента для просмотра данных, сначала нужно было записать
"html" в атрибут $jason.body.background.type, а затем, в атрибут $jason.body.background.text, ввести HTML-код.{
"$jason": {
"head": {
...
},
"body": {
"background": {
"type": "html",
"text": "<html><body><h2>Hello World</h2></body></html>"
}
}
}
} Вполне естественно то, что разработчикам удобнее будет инициализировать контейнер, используя обычную ссылку на веб-страницу, вместо того, чтобы вводить весь HTML-код страницы в одну строчку.
Решение
В Web Container 2.0 появился атрибут
url. Он поддерживает, в частности, локальные файлы. Благодаря использованию конструкции file://... в контейнере можно вывести файл, который поставляется вместе с приложением.{
"$jason": {
"head": {
...
},
"body": {
"background": {
"type": "html",
"url": "file://index.html"
}
}
}
}Аналогично осуществляется и вывод веб-страниц из интернета (с помощью конструкции вида
http[s]://…).{
"$jason": {
"head": {
...
},
"body": {
"background": {
"type": "html",
"url": "https://news.ycombinator.com"
}
}
}
}▍2. Двустороннее взаимодействие приложения и веб-контейнера
Задача
Ранее веб-контейнеры использовались только для вывода некоего содержимого, они не могли взаимодействовать с основным приложением. Это означало, что следующие сценарии их использования были невозможны:
- Воздействие Jasonette на веб-контейнер. А именно, невозможно было вызывать JavaScript-функции, расположенные в контейнере, из Jasonette-приложения.
- Воздействие контейнера на Jasonette. Невозможно было вызывать нативные API из кода, расположенного в контейнере.
Веб-контейнер можно было использовать только для вывода страниц. Это похоже на то, как в обычные веб-страницы встраивают элементы
iframe, когда страница не может получить доступ к тому, что находится внутри этих элементов.Решение
Цель проекта Jasonette заключается в создании стандартного языка разметки, позволяющего описывать кросс-платформенные мобильные приложения. В данном случае нам нужен язык разметки, который может точно описать варианты взаимодействия между родительским приложением и дочерним веб-контейнером.
Для того чтобы этого достичь, я воспользовался технологией JSON-RPC, которая позволила наладить взаимодействие приложения и веб-контейнера. Так как всё в Jasonette выражается в виде JSON-объектов, совершенно естественным было использовать стандартный формат JSON-RPC в качестве коммуникационного протокола.
До использования JSON-RPC Jasonette и веб-контейнер взаимодействовать не могли. После внедрения JSON-RPC стала возможна двусторонняя коммуникация основного приложения и контейнера
Для того чтобы получить возможность вызывать JS-функции, находящиеся в веб-контейнере, мы объявляем действие $agent.request.
{
"type": "$agent.request",
"options": {
"id": "$webcontainer",
"method": "login",
"params": ["username", "password"]
}
}$agent.request — это нативное API, которое инициирует JSON-RPC-запрос к веб-контейнеру. Для того чтобы воспользоваться этим механизмом, нужно передать ему объект
options в качестве параметра.Объект options — это и есть JSON-RPC-запрос, который будет отправлен веб-контейнеру.
Рассмотрим его атрибуты.
id: веб-контейнер построен поверх низкоуровневой архитектуры агентов (agent). Обычно с одним элементомviewможет быть ассоциировано несколько агентов, у каждого из них может быть уникальный идентификатор (ID). Однако веб-контейнер представляет собой особый тип агента, у которого может быть лишь идентификатор$webcontainer, именно поэтому мы используем в запросе данный идентификатор.
method: имя JavaScript-функции, которую нужно вызвать.
params: массив параметров, которые нужно передать вызываемой JS-функции.
Вот как выглядит полный код описываемой разметки:
{
"$jason": {
"head": {
"actions": {
"$load": {
"type": "$agent.request",
"options": {
"id": "$webcontainer",
"method": "login",
"params": ["alice", "1234"]
}
}
}
},
"body": {
"header": {
"title": "Web Container 2.0"
},
"background": {
"type": "html",
"url": "file://index.html"
}
}
}
}Рассмотрим смысл приведённого здесь кода.
При загрузке элемента ($jason.head.actions.$load) нужно выполнить JSON-RPC-запрос, описанный в options, к агенту веб-контейнера ($agent.request).
Параметры веб-контейнера заданы в $jason.body.background, в данном случае здесь осуществляется загрузка локального файла file://index.html.
В ходе обращения к контейнеру будет осуществлён поиск функции login, которой, при вызове, благодаря params, будет передано два аргумента — "alice" и "1234". Выглядеть это будет так:
login("alice", "1234")Тут я рассказал лишь о том, как родительское приложение может вызывать JS-функции из веб-контейнера, однако возможен и обратный процесс, когда контейнер обращается к приложению для вызова нативных API. Подробности об этом можно узнать в документации по агентам.
Пример
Обсудим пример приложения для создания QR-кодов, которое вы уже видели выше.
Приложение для создания QR-кодов
- Компонент для ввода текста в нижней части окна на 100% нативен.
- QR-код генерируется веб-приложением, размещённым в веб-контейнере.
- Когда пользователь вводит некий текст в поле и нажимает кнопку
Generate, осуществляется вызов действия$agent.requestагента веб-контейнера, что приводит к вызову JS-функцииqr.
Код этого приложения можно посмотреть здесь
▍3. Внедрение скриптов
Задача
Иногда нужно динамически внедрять JavaScript-код в веб-контейнеры уже после того, как в них загружен исходный HTML-код.
Представьте, что вы хотите создать собственный веб-браузер. Для этого вам может понадобиться внедрять свои JS-скрипты в каждый веб-контейнер для того, чтобы иметь возможность влиять на его поведение. Собственно говоря, примерно так работают расширения для веб-браузеров.
Даже если вы не занимаетесь разработкой веб-браузера, вам может понадобиться использовать внедрение скриптов в том случае, если вам нужно обеспечить необходимое поведение страниц, которыми вы не можете управлять напрямую. Единственный способ взаимодействия мобильного приложения и веб-контейнера заключается в использовании API $agent. Но если вы не можете изменить HTML-содержимое, единственный способ добавления интерфейса $agent в веб-контейнер заключается в динамическом внедрении скриптов.
Решение
Как уже было сказано, веб-контейнер
$jason.body.background — это всего лишь агент. Это означает, что при работе с ним можно использовать тот же метод $agent.inject, что и при работе с обычными агентами.Внедрение JS-кода в страницу, загруженную в веб-контейнер
▍4. Обработка переходов по URL
Ранее веб-контейнер мог обрабатывать щелчки по ссылкам лишь двумя способами, пребывая в одном из двух режимов.
- В режиме «только чтение» веб-контейнер рассматривается как элемент только для чтения, при этом все события, такие, как касание или прокрутка, игнорируются. Все веб-контейнеры находятся в состоянии только для чтения до тех пор, пока их не переключат в режим обычного браузера, так, как описано ниже.
- В режиме «обычный браузер» веб-контейнер может взаимодействовать со страницей так, как будто мы работаем с обычным браузером. Включить этот режим можно, записав в атрибут
actionзначение"type": "$default".
Задача
Проблема тут заключается в том, что оба рассмотренных выше варианта — это решения представляющие собой концепцию «всё или ничего».
При работе в режиме «только чтение» контейнер игнорирует все воздействия пользователя.
При работе в режиме «обычный браузер» веб-контейнер работает, в буквальном смысле, как браузер. Когда пользователь касается ссылки, страница, на которую ведёт эта ссылка, загружается. При этом у разработчика нет возможности перехватить это событие и вызвать, например, какое-то нативное API.
Решение
Благодаря возможностям нового веб-контейнера можно задать в
$jason.body.background атрибут action, который содержит описание механизма обработки щелчков по ссылкам.Действие для обработки взаимодействий со ссылками
Рассмотрим пример.
{
"$jason": {
"head": {
"actions": {
"displayBanner": {
"type": "$util.banner",
"options": {
"title": "Clicked",
"description": "Link {{$jason.url}} clicked!"
}
}
}
},
"body": {
"background": {
"type": "html",
"url": "file://index.html",
"action": {
"trigger": "displayBanner"
}
}
}
}
}Тут мы прикрепили к веб-контейнеру действие
"trigger": "displayBanner". Это означает, что когда пользователь щёлкает по любой ссылке, выводимой на странице, отображаемой в веб-контейнере, будет вызвано действие displayBanner. При этом сам веб-контейнер не будет обрабатывать щелчок по ссылке.Кроме того, если проанализировать событие displayBanner, можно заметить переменную $jason. В данном случае ссылка, по которой был сделан щелчок, будет передана действию через эту переменную. Например, если щёлкнуть по ссылке, в которой содержится адрес "https://google.com", в $jason попадёт следующее:
{
"url": "https://google.com"
}Это означает, что анализируя значение
$jason.url можно вызывать различные действия.Рассмотрим ещё один пример, представляющий собой реализацию веб-браузера.
{
"$jason": {
"head": {
"actions": {
"handleLink": [{
"{{#if $jason.url.indexOf('signin') !== -1 }}": {
"type": "$href",
"options": {
"url": "file://key.html"
}
}
}, {
"{{#else}}": {
"type": "$default"
}
}]
}
},
"body": {
"background": {
"type": "html",
"url": "file://index.html",
"action": {
"trigger": "handleLink"
}
}
}
}
}Тут мы проверяем, содержит ли URL строку
signin, и, в зависимости от результатов проверки, выполняем различные действия.- Если URL содержит
signin, открывается нативное окно для входа в систему.
- Если URL этой строки не содержит, выполняется действие, задаваемое параметром
"type": "$default", в результате наша программа ведёт себя как обычный браузер.
Примеры
▍Разработка веб-браузера
Теперь мы можем воспользоваться возможностями нового элемента Web Container для разработки приложений. А именно, речь идёт о следующем:
- Возможность стандартной обработки щелчков по ссылкам, что соответствует поведению обычного браузера.
- Возможность обрабатывать щелчки по ссылкам, основываясь на их содержимом.
Всё это даёт нам возможность, например, создать собственный браузер, написав буквально полтора десятка строк JSON-кода. Так как теперь мы можем перехватывать щелчки по ссылкам, мы можем анализировать
$jason.url и выполнять действия, соответствующие различным URL.Рассмотрим пример.
Стандартное поведение браузера
Здесь веб-контейнер ведёт себя как обычный браузер ("type": "$default").
Поведение, основанное на анализе параметра $jason.url
Здесь при щелчке по ссылке применяется нативный переход между страницами.
Этого можно достичь, обрабатывая различные действия, основываясь на значении $jason.url.
Первым шагом создания подобного приложения служит присоединение к веб-контейнеру действия visit.
{
...
"body": {
"background": {
"type": "html",
"url": "https://news.ycombinator.com",
"action": {
"trigger": "visit"
}
}
}
}Второй шаг заключается в выполнении в действии
visit соответствующей операции, основанной на анализе $jason.url.Ниже показано, как мы проверяем, содержатся ли в $jason.url строки newest, show, ask, и так далее (они представляют собой ссылки в верхнем меню). Если нечто подобное удаётся найти — мы позволяем веб-контейнеру вести себя как обычный браузер, задавая значение "type": "$default".
Если соответствия вышеописанному шаблону найти не удалось, мы производим нативный переход $href к новому окну, передавая URL, по которому щёлкнул пользователь, в виде параметра.
...
"actions": {
"visit": [
{
"{{#if /\\/(newest|show|ask)$/.test($jason.url) }}": {
"type": "$default"
}
},
{
"{{#else}}": {
"type": "$href",
"options": {
"url": "https://jasonette.github.io/Jasonpedia/webcontainer/agent/hijack.json",
"preload": {
"background": "#ffffff"
},
"options": {
"url": "{{$jason.url}}"
}
}
}
}
]
},Здесь можно посмотреть полный JSON-код этого примера, который, кстати, занимает всего 48 строк.
▍Быстрая разработка «гибридного» приложения
Под «гибридными» приложениями обычно подразумевают обычные веб-приложения, «завёрнутые» в нативные мобильные приложения.
Однако тут мы имеем в виду кое-что другое. В нашем случае речь идёт о настоящих гибридных приложениях, когда у одного и того же приложения может одновременно быть несколько нативных представлений и несколько веб-представлений. Кроме того, одно представление такого приложения может иметь несколько нативных компонентов пользовательского интерфейса и веб-контейнер, причём, всё это выводится в одном нативном макете.
Переход между элементом управления, выводящим веб-содержимое и стандартными элементами управления должен быть настолько незаметным, чтобы сложно было бы обнаружить границу между ними.
Гибридное приложение
В этом примере я создал приложение, которое выводит сайт jasonbase.com в веб-контейнере, выступающем в роли основного элемента для визуализации данных.
Jasonbase — это бесплатный хостинг, который я создал специально для размещения JSON-разметки приложений, основанных на Jasonette.
На самом деле, это — обычный сайт, но я встроил его в Jasonette-приложение, в результате, при щелчках по ссылкам, вместо обычной процедуры открытия веб-страницы, вызывается нативный переход $href в нативном же элементе JASON.
Мне не пришлось дорабатывать код Jasonbase.com для того, чтобы создать это приложение. Я просто встроил веб-сайт в Jasonette-приложение в виде веб-контейнера и перехватил щелчки по ссылкам для обработки их нативными средствами, что, в частности, позволило воспользоваться переходами, и, при необходимости, позволит пользоваться и другими возможностями платформы, на котором работает приложение.
Код этого примера можно найти здесь.
Итоги
Полагаю, что всё это замечательно работает по той причине, что все сложные действия выполняются на уровне фреймворка, а этот уровень скрыт от разработчика.
При обычном подходе разработчику, для того, чтобы достичь похожего результата, пришлось бы взять на себя решение следующих задач:
- Встраивание веб-контейнера в нативный макет.
- Создание JavaScript-моста, позволяющего приложению вызывать функции из контейнера.
- Создание системы обработки событий, благодаря которой контейнер может обращаться к основному приложению, вызывая нативные API.
Решением этих проблем, в случае с Jasonette, стало создание уровня абстракции, состоящего из следующих основных частей:
- Декларативный язык разметки, который служит для описания того, как именно веб-контейнер должен быть встроен в нативное приложение.
- Коммуникационный протокол (JSON-RPC), который, крайне просто, позволяет организовать взаимодействие между родительским приложением и веб-контейнером.
Не берусь говорить о том, что это — решение всех проблем, но я с удовольствием отмечаю, что то, о чём я тут рассказал, очень пригодилось мне.
Я пытался создать приложение, использующее новейшую технологию, у которой не было стабильной и надёжной мобильной реализации (и неясно было, появится ли нечто подобное в обозримом будущем из-за особенностей того, о чём я говорю). Однако, к моему счастью, имелась JS-реализация этой технологии, что позволило мне без проблем интегрировать её в приложение.
В целом, говоря о новых возможностях Jasonette, могу сказать, что то, что получилось, мне очень нравится. Вот, кстати, документация по проекту, отражающая нововведения.
Теперь мне хотелось бы сделать одно важное, на мой взгляд, замечание: «Большая сила — это большая ответственность». Возможности, которые обрёл проект Jasonette, огромны, поэтому, полагаю, разработчикам, пользующимся этим фреймворком, нужно помнить о балансе возможностей мобильных платформ и HTML, позволяющем создавать приложения, с которыми будет удобно и приятно работать.
Кто-то может взять Jasonette и создать приложение, основанное исключительно на веб-контейнерах. Такое «приложение» правильнее будет называть «веб-сайтом». Подобный подход ставит под вопрос необходимость создания выделенного приложения.
Я хочу обратить ваше внимание на то, что я не призываю к тому, чтобы всегда создавать приложения, в которых обязательно используются и возможности мобильных платформ, и HTML-страницы. Я лишь пытаюсь сказать, что подобный подход может оказаться полезным во множестве ситуаций. Однако тут важно не перестараться, не перейти границы разумного использования технологий.
В итоге хочу сказать, что существует множество ситуаций, в которых возможности обмена данными между базовым приложением Jasonette и веб-контейнером позволяют креативно и красиво решать самые разные задачи. Надо отметить, что здесь мы обсудили лишь основы. Самое интересное — впереди.
Уважаемые читатели! Планируете ли вы использовать Jasonette для разработки кросс-платформенных мобильных приложений?
Введение
Разрабатывая и отлаживая проект в Visual Studio, вы, как правило, делаете это, компилируя код в Debug-конфигурации. На боевой же сервер проект выкладывается, откомпилированный в Release-конфигурации. И каждый проект рано или поздно разрастается настолько, что в нём появляется некий «отладочный» или «релизный» код — то есть, тот код, который должен работать только в одной из конфигураций. И если бы дело ограничивалось только кодом, то директива условной компиляции #if решала бы все проблемы. Но обычно за кодом ещё тянутся настройки, специфичные для каждой из конфигураций, а зачастую и разметка веб-страниц. В самом начале, когда такие проблемы только начинают появляться, и ещё не являются сильной головной болью, обычно используется банальное комментирование ненужных в конкретный момент строк с кодом/разметкой/настройками. Но это — Road To Hell в самом чистом виде. А вот о Stairway To Heaven я и хотел бы рассказать.
Когда я впервые столкнулся с такой проблемой и уже погряз в костылях из комментариев и наборов различных конфигурационных файлов, то в какой-то момент решил поинтересоваться чужим опытом, а также получше изучить возможности среды разработки и используемых инструментов. И внезапно выяснил, что все мои искусственные костыли являются абсолютно избыточными — проблема может быть решена стандартными средствами и без ухудшения читаемости кода. Итоги моего исследования я опишу в небольшом цикле статей, где рассмотрю и примеры проблем с окружением, и механизмы, с помощью которых весь код, настройки и html-разметку автоматически можно привести в нужный вид при публикации проекта. Речь при этом пойдёт о разработке ASP.NET MVC-приложений, как области, в которой я, в основном, и работаю. Однако, всё написанное будет применимо к любой .NET-разработке в Visual Studio.
Создание веб-приложения на Go в 2017 году / Хабр
Пару недель назад я начал разрабатывать еще одно веб-приложение, только уже на Go. Будучи, в основном, бэкэнд-разработчиком, я не часто писал веб-приложения целиком, поэтому каждый такой случай больше походил на вызов. В такие моменты хотелось, чтобы кто-нибудь написал руководство по веб-разработке для людей, у которых нет возможности целыми днями вникать в тонкости отличного дизайна, но которым просто нужно создать работающий, функциональный сайт без лишней суеты.
Я решил воспользоваться этой возможностью и сделать такое руководство, в котором начать с нуля веб-приложение так, как это должно быть сделано в 2017 году (в моем понимании). Я провел много часов, докапываясь до тех вещей, которых раньше обычно избегал, просто для того, чтобы хотя бы раз за много лет я мог с уверенностью заявить, что у меня есть свой взгляд и опыт в этом вопросе, и получить для себя работающий рецепт, который, возможно, пригодится не только мне.
Статья начинает короткую серию, освещающаю то, что я узнал в процессе. Этот первый пост представляет собой общее введение, описывающее текущее положение дел, проблемы и то, почему я считаю Go хорошим выбором. Последующие статьи будут более детальными и содержать больше кода. Мне любопытно, насколько мой опыт коррелирует с вашим; может быть я в чем-то ошибаюсь, так что не стесняйтесь комментировать.
Если вас интересует только код, он тут.
Введение
Раньше моих базовых знаний HTML, CSS и JavaScript было достаточно для моих скромных нужд в сайтостроении. Большинство приложений, которые я когда-либо создавал, были сделаны с помощью mod_python, напрямую используя механизм публикации обработчиков (прим.пер.: пример можно посмотреть тут). Забавно, что будучи ранним последователем Python, я также немало поработал с Rails. В течение последних нескольких лет я сосредоточился на инфраструкте (больших) данных, которая вовсе не является веб-разработкой, хотя необходимость в веб-интерфейсах тут — не редкость. Фактически, приложение, которым я сейчас занимаюсь, является приложением для работы с данными, но оно не опенсорсное и то, что оно делает, не имеет значения для данной статьи. В общем, это должно прояснить, с какой стороны я на все это смотрю.
Python и Ruby
Еще год назад я бы рекомендовал Python или Ruby в качестве среды веб-приложения. Может быть есть и другие подобные языки, но с моей точки зрения, в мире доминируют Python и Ruby.
Большую часть времени главной задачей веб-приложения было конструирование веб-страниц с помощью компоновки конечного HTML на стороне сервера. Как Python, так и Ruby очень хорошо подходят для извлечения данных из БД и превращению их в кучу HTML-кода с помощью шаблонов. Существует множество фреймворков/инструментов на выбор, например, Rails, Django, Sinatra, Flask и т.д. и т.п.
И хотя эти языки имеют определенные существенные ограничения, такие как GIL, легкость, с которой они решают проблему генерации HTML, намного ценнее компромиссов, на которые приходится идти.
GIL
GIL (Global Interpreter Lock) залуживает отдельного упоминания. Безусловно, это самое большое ограничение любого решения на Python или Ruby, но это очень скользкая тема, люди чаще предпочитают делать вид, что проблемы нет. А если уж речь об этом зашла, эмоции обычно бьют через край, в сообществах Ruby и Python идут бесконечные обсуждения на тему GIL.
Для тех, кто незнаком с этой проблемой — GIL позволяет выполнятся только одной вещи за раз. Когда вы создаете потоки и они ”выглядят” как параллельно выполняющиеся, на самом деле интерпретатор все еще выполняет инструкции последовательно. Это означает, что один процесс может использовать только один CPU.
Существуют альтернативные реализации, например, основанные на JVM, но они нечасто применяются. Я точно не знаю почему, возможно они не полностью совместимы или, вероятно, не поддерживают корректно C-расширения, и у них при этом все еще может быть GIL. Не уверен, но насколько я могу судить, обычно все-таки используется реализация на C. Чтобы сделать интерпретатор без GIL, придется его полностью переписать, а это уже может изменить поведение языка (в моем наивном понимании), и поэтому мне кажется, что GIL останется.
Веб-приложения любого значительного масштаба обязательно требуют возможность обслуживания запросов параллельно, используя возможности каждого имеющегося у машины CPU. Пока единственным возможным решением остается запуск нескольких экземпляров приложения как отдельных процессов.
Обычно это делается с помощью дополнительного ПО, такого как Unicorn/Gunicorn, при этом каждый процесс слушает свой собственный порт и запускается позади какого-то балансировщика соединения, типа Nginx и/или Haproxy. Альтернативно это может быть сделано через Apache и его модули (такие как mod_python или mod_wsgi), в любом случае это сложно. Такие приложения обычно полагаюся на сервер базы данных в качестве арбитра для любых, чувствительных к конкурентности, задач. При реализации кэширования, чтобы не хранить множество копий одного и того же на одном и том же сервере, требуется хранилище с разделяемой памятью, типа Memcached или Redis, а обычно оба. Также такие приложения не могут делать фоновую обработку, для этого существует отдельный набор инструментов, такой как Resque. И потом все эти компоненты требуют мониторинга, чтобы быть уверенным, что все это работает. Логи должны быть консолидированными, и для них есть свои дополнительные инструменты. Учитывая неизбежную сложность этой настройки, также требуется наличие менеджера конфигурации, такого как Chef или Puppet. И тем не менее, эти наборы, как правило, не способны поддерживать большое количество долговременных соединений — проблема известная как C10K.
В итоге простое веб-приложение с базой данных требует целую кучу составных частей, прежде чем оно сможет обслуживать страницу «Hello World!». И почти все это из-за GIL.
Появление одностраничных приложений
Все дальше и дальше в прошлое уходит генерация HTML на сервере. Последняя (и правильная) тенденция заключается в построении пользовательского интерфейса и рендеринге полностью на стороне клиента, с помощью JavaScript. Приложения, чей пользовательский интерфейс полностью управляется JS, иногда называют одностраничным приложением и, на мой взгляд, за ними будущее, нравится нам это или нет. В таких приложениях сервер только обслуживает данные, обычно в виде JSON, не создавая HTML-кода. В этом случае та огромная сложность, введенная в первую очередь для возможности использования популярного скриптового языка [для создания веб-прилолжения], оказывается ненужной. Особенно учитывая, что Python или Ruby приносят мало выгоды, когда весь вывод — это JSON.
Взгляд на Golang
Go постепенно подрывает устоявшийся мир веб-приложений. Он нативно поддерживает параллельное выполнение, что устраняет потребность почти во всех компонентах, обычно используемых для работы с ограничениями GIL.
Программы на Go представляют собой бинарники, которые нативно запускаются, так что не требуется ничего языкоспецифического устанавливать на сервер. Исчезает проблема обеспечения правильной версии среды исполнения, требуемой приложением; отдельной среды исполнения нет — она встроена в бинарник. Программы на Go могут легко и элегантно запускать задачи в фоне, поэтому нет нужды в инструментах типа Resque. Эти программы запускаются как единственный процесс, так что кэширование становится тривиальным, а значит, Memcached или Redis не нужны. Go может управлять неограниченным количеством параллельных соединений, нивелируя надобность в фронтэндной защите, такой как Nginx.
С Go высокая многослойная башня из Python, Ruby, Bundler, Virtualenv, Unicorn, WSGI, Resque, Memcached, Redis, и т.д., и т.п. уменьшается до всего лишь одного бинарника. Единственный сторонний компонент, который обычно все еще нужен, — это база данных (я бы посоветовал PostgreSQL). Тут важно отметить, что все эти инструменты по прежнему можно использовать, но с Go можно обойтись и без них.
Время запуска такой Go-программы будет, скорее всего, на порядок превосходить любое приложение на Python/Ruby, потребует меньше памяти и строк кода.
Хорошо, а есть популярный фреймворк?
Краткий ответ таков: фреймворк является необязательным и не рекомендуется. Существует множество проектов, претендующих на роль отличного фреймворка, но я считаю, что лучше обойтись без них. Это не только мое личное мнение, я нахожу это мнение довольно распространенным в сообществе Go.
Надо понимать, зачем вообще были созданы фреймворки. В мире Python/Ruby так случилось потому, что эти языки не были изначально спроектированы для обслуживания веб-страниц, и для решения этой задачи необходимо было множество внешних компонентов. То же самое можно сказать и про Java, который, как и Python, и Ruby, стары как веб, каким мы его знаем, или даже немного старше.
Насколько я помню, ранние версии Python «из коробки» не предоставляли ничего для работы с базой данных, не было шаблонов, поддержка HTTP была запутанной, работа с сетью — нетривиальной, даже шифрование тогда было незаконным и в общем, много чего еще отсутствовало. Фреймворк обеспечивал все эти необходимые кусочки и устанавливал характерные для языка правила разработки для всех распространенных вариантов веб-приложений.
Go, с другой стороны, создавался людьми, которые уже имели опыт и разбирались в веб-разработке. Он включает в себя практически все необходимое. Один-два внешних пакета могут понадобиться для решения некоторых конкретных задач, типа OAuth, но ни в коем случае эта пара пакетов не является «фреймворком».
Если все вышеприведенное касаемо фреймворков звучит не достаточно убедительно, полезно рассмотреть кривую обучения для фреймворков и риски. Мне понадобилось около двух лет, чтобы наладить отношения с Rails. Фреймворки могут стать заброшенными и устаревшими, а переносить приложение на новый фреймворк тяжело, а иногда и невозможно. Учитывая, как быстро все меняется в информационных технологиях, фреймворк уж точно не следует выбирать легкомысленно.
Я хотел бы особо выделить инструменты и фреймворки, которые пытаются имитировать идиомы, общие для Python, Ruby или сред JavaScript. Все, что выглядит, или ощущается, или претендует на роль «Rails for Go», включая такие техники, как инъекции, динамическая публикация методов и т.п., которые сильно зависят от рефлексии, не вписывается в идеологию Go, поэтому лучше от такого держаться подальше.
Несомненно, фреймворки делают некоторые вещи проще, особенно в типичном мире CRUD-приложений для бизнеса, где приложения имеют множество страниц с большим количеством полей, манипулируют данными в сложных и постоянно меняющихся схемах баз данных. Не уверен, что в такой среде Go — хороший выбор, особенно если производительность и масштабируемость не в приоритете.
Другая проблема, общая для фреймворков, это то, что они абстрагируют низкоуровневые механизмы от разработчика так, что со временем они становятся настолько загадочными, что буквально невозможно понять, что у них там на самом деле происходит. То, что начинается с лексического псевдонима для одной строки JavaScript становится слоем в слоях транспайлеров, минимайзеров, поверх хелперов, скрытых где-то в подзависимостях. Однажды что-то ломается, и невозможно понять, где искать проблему. Приятно, когда точно знаешь, что происходит, и Go в этом очень хорош.
Как насчет базы данных и ORM?
Аналогично фреймворкам, ORM’ы в Go не сильно распространены. Для начала, Go не поддерживает объекты — то, что обозначено O в аббревиатуре ORM.
Я знаю, если вместо того, чтобы пользоваться удобным User.find(:all).filter..., которое обеспечивается чем-то вроде ActiveRecord, писать SQL вручную — это нечто неслыханное в некоторых сообществах, но я все-таки думаю, что такое отношение должно измениться. SQL — прекрасный язык. Иметь дело с SQL напрямую — это не так уж сложно, а взамен мы получаем больше свободы и возможностей. Пожалуй, самой утомительной частью такой прямой работы является копирование данных из курсора базы данных в структуры, но здесь очень пригодится проект sqlx.
Заключение
На мой взгляд, статья достаточно подробно описывает текущую ситуацию на стороне сервера. Я думаю, клиентскую часть лучше выделить в отдельный пост, поэтому на сегодня — все. Подводя итог, мы строим приложение примерно со следующими требованиями:
- Минимальная зависимость от сторонних пакетов.
- Без веб-фреймворка.
- PostgreSQL в качестве БД.
- Одностраничное приложение.
Продолжение
Создание нового веб-приложения
Доступ к данным был прекращен. Пожалуйста, обратитесь к этой странице для получения дополнительной информации.В этом руководстве вы создадите новое веб-приложение ASP.NET, которое вы можете использовать в качестве отправной точки для своего приложения.
- Запустите Visual Studio, в меню Файл выберите Новый , а затем выберите Проект .
- В диалоговом окне Новый проект выберите Visual Basic или Visual C # в качестве языка программирования.
На панели Шаблоны выберите Пустое веб-приложение ASP.NET и назовите проект SofiaCarRentalWebApp .
Нажмите OK , чтобы создать решение и проект.
- Добавьте в проект файл Global Application Class ( Global.asax ).
- Добавьте новую веб-форму с именем По умолчанию к проекту.
- Интегрировать Telerik.DataAccess.Core NuGet пакет с проектом SofiaCarRentalWebApp .
- Следуя инструкциям в руководстве по созданию модели SofiaCarRental, создайте проект SofiaCarRental.Model , в котором хранится свободная модель.
- В проекте SofiaCarRentalWebApp добавьте ссылку на проект SofiaCarRental.Model .
Скопируйте строку подключения SofiaCarRentalConnection из файла App.config SofiaCarRental.Проект модели для файла Web.config проекта SofiaCarRentalWebApp .
Выберите Telerik.Откройте ссылку OpenAccess.dll в SofiaCarRentalWebApp и нажмите F4, чтобы открыть панель свойств. Установите для свойства Copy Local значение True .
- Постройте решение .
В этой задаче вы создали новое веб-приложение ASP.NET и свободную модель SofiaCarRental. Далее вы начнете реализовывать пользовательский интерфейс.
См. Также
,- 10 минут, чтобы прочитать
В этой статье
В этом руководстве показано, как использовать портал Azure для создания шлюза приложений с брандмауэром веб-приложений (WAF).WAF использует правила OWASP для защиты вашего приложения. Эти правила включают защиту от таких атак, как внедрение SQL, межсайтовый скриптинг и перехват сеансов. После создания шлюза приложения проверьте его работоспособность. Azure Application Gateway позволяет направлять веб-трафик приложения на определенные ресурсы, назначая прослушиватели для портов, создавая правила и добавляя ресурсы в бэкэнд-пул. Для простоты в этом учебнике используется простая настройка с общедоступным внешним IP-адресом, базовый прослушиватель для размещения одного сайта на этом шлюзе приложений, две виртуальные машины, используемые для внутреннего пула, и базовое правило маршрутизации запросов.
Из этого урока вы узнаете, как:
- Создание шлюза приложений с включенным WAF
- Создание виртуальных машин, используемых в качестве внутренних серверов
- Создайте учетную запись хранения и настройте диагностику
- Тестирование шлюза приложений
Примечание
Эта статья была обновлена для использования новой Azure PowerShell Az модуль. Вы по-прежнему можете использовать модуль AzureRM, который будет получать исправления ошибок как минимум до декабря 2020 года.Чтобы узнать больше о новом модуле Az и совместимости AzureRM, см. Представляем новый модуль Azure PowerShell Az. Для Инструкции по установке модуля Az см. В разделе Установка Azure PowerShell.
Если у вас нет подписки Azure, создайте бесплатную учетную запись, прежде чем начать.
Войдите в Azure
Войдите на портал Azure по адресу https://portal.azure.com.
Создайте шлюз приложений
Для взаимодействия Azure между ресурсами необходима виртуальная сеть.Вы можете создать новую виртуальную сеть или использовать существующую. В этом примере вы создаете новую виртуальную сеть. Вы можете создать виртуальную сеть одновременно со шлюзом приложения. Экземпляры шлюза приложений создаются в отдельных подсетях. В этом примере вы создаете две подсети: одну для шлюза приложений, а другую для внутренних серверов.
Выберите . Создайте ресурс в левом меню портала Azure. Новое окно появляется.
Выберите Networking , а затем выберите Application Gateway в списке Featured .
Вкладка «Основы»
На вкладке Основы введите эти значения для следующих настроек шлюза приложения:
Группа ресурсов : выберите myResourceGroupAG для группы ресурсов. Если он не существует, выберите Создать новый , чтобы создать его.
Имя шлюза приложения : введите myAppGateway в качестве имени шлюза приложения.
Уровень : выберите WAF V2 .
Для взаимодействия Azure между создаваемыми ресурсами необходима виртуальная сеть. Вы можете создать новую виртуальную сеть или использовать существующую. В этом примере вы создадите новую виртуальную сеть одновременно с шлюзом приложения. Экземпляры шлюза приложений создаются в отдельных подсетях. В этом примере вы создаете две подсети: одну для шлюза приложений, а другую для внутренних серверов.
В соответствии с Настройте виртуальную сеть , создайте новую виртуальную сеть, выбрав Создать новый . В открывшемся окне Создать виртуальную сеть введите следующие значения для создания виртуальной сети и двух подсетей:
Имя : введите myVNet в качестве имени виртуальной сети.
Имя подсети (Подсеть шлюза приложений): В сетке Подсети будет показана подсеть с именем По умолчанию .Измените имя этой подсети на myAGSubnet .
Подсеть шлюза приложений может содержать только шлюзы приложений. Другие ресурсы не разрешены.Имя подсети (подсеть внутреннего сервера): Во второй строке сетки Подсети введите myBackendSubnet в столбце Имя подсети .
Диапазон адресов (подсеть внутреннего сервера): во второй строке сетки подсетей введите диапазон адресов, который не перекрывается с диапазоном адресов myAGSubnet .Например, если диапазон адресов myAGSubnet равен 10.0.0.0/24, введите 10.0.1.0/24 для диапазона адресов myBackendSubnet .
Выберите OK , чтобы закрыть окно Создать виртуальную сеть и сохранить настройки виртуальной сети.
На вкладке Основы примите значения по умолчанию для других настроек и выберите Далее: Frontends .
Вкладка веб-интерфейсов
На вкладке Frontend убедитесь, что для IP-адреса типа внешнего интерфейса установлено значение Public .
Можно настроить внешний IP-адрес как открытый или частный в соответствии с вашим вариантом использования. В этом примере вы выберете публичный IP-адрес.Примечание
Для SKU Application Gateway v2 вы можете выбрать только конфигурацию IP-интерфейса Public . Конфигурация IP частного интерфейса в настоящее время не включена для этого v2 SKU.
Выберите Создайте новый для общего IP-адреса и введите myAGPublicIPAddress в качестве имени общего IP-адреса, а затем выберите OK .
Выберите Далее: Backends .
Вкладка Backends
Внутренний пул используется для маршрутизации запросов к внутренним серверам, которые обслуживают запрос. Внутренние пулы могут состоять из сетевых адаптеров, наборов масштабов виртуальных машин, общедоступных IP-адресов, внутренних IP-адресов, полных доменных имен (FQDN) и мультитенантных серверных частей, таких как служба приложений Azure. В этом примере вы создадите пустой пул бэкэнда со своим шлюзом приложения, а затем добавите бэкэнд-цели в бэкэнд-пул.
На вкладке Бэкэнды выберите + Добавить бэкэнд-пул .
В открывшемся окне Добавить внутренний пул введите следующие значения для создания пустого внутреннего пула:
- Имя : введите myBackendPool в качестве имени внутреннего пула.
- Добавить бэкэнд-пул без целей : Выберите Да , чтобы создать бэкэнд-пул без целей. После создания шлюза приложения вы добавите конечные цели.
В окне Добавить внутренний пул выберите Добавить , чтобы сохранить конфигурацию внутреннего пула и вернуться на вкладку Бэкенд .
На вкладке Backends выберите Далее: Конфигурация .
Вкладка конфигурации
На вкладке Конфигурация вы подключите созданный интерфейсный и внутренний пул с помощью правила маршрутизации.
Выберите Добавить правило в столбце Правила маршрутизации .
В открывшемся окне Добавить правило маршрутизации введите myRoutingRule для имени правила .
Для правила маршрутизации требуется прослушиватель. На вкладке Слушатель в окне Добавить правило маршрутизации введите следующие значения для слушателя:
Имя слушателя : Введите myListener в качестве имени слушателя.
IP-интерфейс внешнего интерфейса : выберите Public , чтобы выбрать общедоступный IP-адрес, созданный для внешнего интерфейса.
Примите значения по умолчанию для других параметров на вкладке Прослушиватель , затем выберите вкладку Внутренние цели , чтобы настроить остальную часть правила маршрутизации.
На вкладке Внутренние цели выберите myBackendPool для целевой базы .
Для параметра HTTP выберите Создать новый , чтобы создать новый параметр HTTP. Настройка HTTP будет определять поведение правила маршрутизации.В открывшемся окне Добавить настройки HTTP введите myHTTPSetting для имени настройки HTTP . Примите значения по умолчанию для других параметров в окне Добавить параметр HTTP , затем выберите Добавить , чтобы вернуться к окну Добавить правило маршрутизации .
В окне Добавить правило маршрутизации выберите Добавить , чтобы сохранить правило маршрутизации и вернуться на вкладку Конфигурация .
Выберите Далее: теги , а затем Далее: Обзор + создать .
Обзор + создать вкладку
Просмотрите параметры на вкладке Просмотр + создание , а затем выберите Создать , чтобы создать виртуальную сеть, общедоступный IP-адрес и шлюз приложения. Azure может занять несколько минут для создания шлюза приложения.
Дождитесь успешного завершения развертывания, прежде чем переходить к следующему разделу.
Добавить внутренние цели
В этом примере вы будете использовать виртуальные машины в качестве целевого сервера. Вы можете использовать существующие виртуальные машины или создавать новые. Вы создадите две виртуальные машины, которые Azure использует в качестве внутренних серверов для шлюза приложений.
Для этого вам понадобится:
- Создайте две новые виртуальные машины: myVM и myVM2 , которые будут использоваться в качестве внутренних серверов.
- Установите IIS на виртуальных машинах, чтобы убедиться, что шлюз приложений был успешно создан.
- Добавьте внутренние серверы в внутренний сервер.
Создать виртуальную машину
На портале Azure выберите Создать ресурс . Новое окно появляется.
Выберите Windows Server 2016 Datacenter в списке Популярные . Откроется страница Создание виртуальной машины .
Шлюз приложений может направлять трафик на виртуальные машины любого типа, используемые в его внутреннем пуле.В этом примере вы используете Windows Server 2016 Datacenter.Введите эти значения на вкладке Основы для следующих настроек виртуальной машины:
- Группа ресурсов : выберите myResourceGroupAG в качестве имени группы ресурсов.
- Имя виртуальной машины : введите myVM в качестве имени виртуальной машины.
- Имя пользователя : введите azureuser в качестве имени пользователя администратора.
- Пароль : введите Azure123456! для пароля администратора.
Примите другие значения по умолчанию и выберите Далее: Диски .
Примите значения по умолчанию для вкладки Диски и выберите Далее: Сеть .
На вкладке Networking убедитесь, что выбрано myVNet для виртуальной сети , а для подсети установлено значение myBackendSubnet .Примите другие значения по умолчанию и выберите Далее: Управление .
Шлюз приложений может взаимодействовать с экземплярами вне виртуальной сети, в которой он находится, но вам необходимо убедиться, что есть возможность подключения по IP.На вкладке Управление установите для параметра Диагностика загрузки значение Выкл. . Примите другие значения по умолчанию и выберите Просмотр + создать .
На вкладке Просмотр + создание просмотрите параметры, исправьте все ошибки проверки и выберите Создать .
Прежде чем продолжить, дождитесь завершения создания виртуальной машины.
Установите IIS для тестирования
В этом примере вы устанавливаете IIS на виртуальные машины только для проверки того, что Azure успешно создал шлюз приложения.
Откройте Azure PowerShell. Для этого выберите Cloud Shell в верхней панели навигации портала Azure, а затем выберите PowerShell в раскрывающемся списке.
Выполните следующую команду для установки IIS на виртуальной машине:
Set-AzVMExtension` -ResourceGroupName myResourceGroupAG ` -ExtensionName IIS ` -VMName myVM` Издатель Microsoft.Вычислить -ExtensionType CustomScriptExtension ` -TypeHandlerVersion 1.4 ` -SettingString '{"commandToExecute": "Web-сервер powershell Add-WindowsFeature; Add-Content Powerhell -Path \" C: \\ inetpub \\ wwwroot \\ Default.htm \ "-Value $ ($ env: computername)" } '` -Расположение EastUSСоздайте вторую виртуальную машину и установите IIS, используя ранее выполненные действия. Используйте myVM2 для имени виртуальной машины и для параметра VMName для командлета Set-AzVMExtension .
Добавление внутренних серверов в внутренний пул
Выберите Все ресурсы , а затем выберите myAppGateway .
Выберите Бэкэнд-пулы в левом меню.
Выберите myBackendPool .
В поле Цели выберите Виртуальная машина из раскрывающегося списка.
В разделе VIRTUAL MACHINE и NETWORK INTERFACES выберите виртуальные машины myVM и myVM2 и связанные с ними сетевые интерфейсы из раскрывающихся списков.
Выберите Сохранить .
Дождитесь завершения развертывания, прежде чем переходить к следующему шагу.
Создайте учетную запись хранения и настройте диагностику
Создать учетную запись хранения
Для этой статьи шлюз приложений использует учетную запись хранения для хранения данных в целях обнаружения и предотвращения. Вы также можете использовать журналы Azure Monitor или Event Hub для записи данных.
- Выберите . Создайте ресурс в верхнем левом углу портала Azure.
- Выберите Storage , а затем выберите Storage account .
- Для Группа ресурсов , выберите myResourceGroupAG для группы ресурсов.
- Введите myagstore1 в качестве имени учетной записи хранения.
- Примите значения по умолчанию для других настроек и затем выберите Просмотр + Создать .
- Проверьте настройки и выберите Создать .
Настроить диагностику
Настройка диагностики для записи данных в журналы ApplicationGatewayAccessLog, ApplicationGatewayPerformanceLog и ApplicationGatewayFirewallLog.
В левом меню выберите Все ресурсы , а затем выберите myAppGateway .
В разделе «Мониторинг» выберите Настройки диагностики .
выберите Добавить настройку диагностики .
Введите myDiagnosticsSettings в качестве имени для настроек диагностики.
Выберите Архивировать в учетную запись хранения , затем выберите Настроить , чтобы выбрать ранее созданную учетную запись хранения myagstore1 , а затем выберите OK .
Выберите журналы шлюза приложения для сбора и хранения.
Выберите Сохранить .
Создание и связывание политики брандмауэра веб-приложений
Все настройки и настройки WAF находятся в отдельном объекте, который называется политикой WAF. Политика должна быть связана с вашим шлюзом приложений. Чтобы создать Политику WAF, см. Создание Политики WAF. После его создания вы можете связать политику с вашим WAF (или отдельным слушателем) из Политики WAF на вкладке Ассоциированные прикладные шлюзы .
Тестирование шлюза приложений
Хотя IIS не требуется для создания шлюза приложения, вы установили его, чтобы проверить, успешно ли Azure создал шлюз приложения. Используйте IIS для тестирования шлюза приложения:
Найдите общедоступный IP-адрес шлюза приложений на его странице Обзор .
Или вы можете выбрать Все ресурсы , ввести myAGPublicIPAddress в поле поиска, а затем выбрать его в результатах поиска.Azure отображает общедоступный IP-адрес на странице Overview .
Скопируйте общедоступный IP-адрес и вставьте его в адресную строку браузера.
Проверьте ответ. Правильный ответ подтверждает, что шлюз приложения был успешно создан и может успешно подключиться к бэкэнду.
Очистка ресурсов
Если вам больше не нужны ресурсы, созданные вами с помощью шлюза приложений, удалите группу ресурсов.Удаляя группу ресурсов, вы также удаляете шлюз приложения и все связанные с ним ресурсы.
Для удаления группы ресурсов:
- В левом меню портала Azure выберите Группы ресурсов .
- На странице Группы ресурсов найдите myResourceGroupAG в списке и выберите его.
- На странице группы ресурсов выберите Удалить группу ресурсов .
- Введите myResourceGroupAG для ТИП НАЗВАНИЕ ГРУППЫ РЕСУРСОВ , а затем выберите Удалить .
Следующие шаги
,An Сервер приложений позволяет вам работать с серверными ресурсами, такими как в качестве базы данных. Например, динамическая страница может указывать приложению сервер для извлечения данных из базы данных и вставки их в страницу HTML. Для получения дополнительной информации см. Www.adobe.com/go/learn_dw_dbguide.
Использование база данных для хранения контента позволяет вам отделить ваш веб-сайт дизайн из контента, который вы хотите показать пользователям сайта. Вместо написания отдельных файлов HTML для каждой страницы, вам нужно только написать страницу — или шаблон — для различных видов информации Вы хотите представить.Затем вы можете загрузить контент в базу данных а затем сделать так, чтобы веб-сайт извлекал этот контент в ответ пользователю запрос. Вы также можете обновить информацию в одном источнике, и затем внесите это изменение по всему сайту, не имея вручную редактировать каждую страницу. Вы можете использовать Adobe Dreamweaver для разработка веб-форм для вставки, обновления или удаления данных из базы данных.
Инструкция по извлечению данных из базы данных называется базой данных запрос . Запрос состоит из критериев поиска, выраженных в язык базы данных называется SQL (язык структурированных запросов).SQL запрос записывается в серверные скрипты или теги страницы.
Сервер приложений не может общаться напрямую с базой данных, потому что собственный формат базы данных делает данные не расшифровываются во многом так же, как Microsoft Word Документ, открытый в Блокноте или BBEdit, может быть не расшифрован. Сервер приложений может общаться с базой данных только через посредник драйвера базы данных: программное обеспечение, которое действует как интерпретатор между сервером приложений и базой данных.
После драйвер устанавливает связь, запрос выполняется против база данных и набор записей созданы. Набор записей набор данных, извлеченных из одной или нескольких таблиц в базе данных. набор записей возвращается на сервер приложений, который использует данные для завершения страницы.
Вот простой запрос к базе данных, написанный на SQL:
.Руководство по. Регистрация приложения — Azure AD B2C
- 4 минуты, чтобы прочитать
В этой статье
Прежде чем ваши приложения смогут взаимодействовать с Azure Active Directory B2C (Azure AD B2C), они должны быть зарегистрированы в управляемом вами клиенте.В этом руководстве показано, как зарегистрировать веб-приложение с помощью портала Azure.
В этой статье вы узнаете, как:
- Зарегистрируйте веб-приложение
- Создать секрет клиента
Если вы вместо этого используете нативное приложение (например, iOS, Android, мобильные и настольные ПК), узнайте, как зарегистрировать нативное клиентское приложение.
Если у вас нет подписки Azure, создайте бесплатную учетную запись, прежде чем начать.
Предпосылки
Если вы еще не создали своего собственного клиента Azure AD B2C, создайте его сейчас.Вы можете использовать существующего клиента Azure AD B2C.
Зарегистрируйте веб-приложение
Чтобы зарегистрировать приложение в своем клиенте Azure AD B2C, вы можете использовать нашу новую унифицированную регистрацию приложений или нашу прежнюю версию Applications (Legacy) . Узнайте больше о новом опыте.
Войдите на портал Azure.
Выберите значок Каталог + подписка на панели инструментов портала, а затем выберите каталог, в котором содержится клиент Azure AD B2C.
На портале Azure найдите и выберите Azure AD B2C .
Выберите регистрации приложений , а затем выберите Новая регистрация .
Введите Имя для приложения. Например, webapp1 .
В разделе Поддерживаемые типы учетных записей выберите Учетные записи в любом каталоге организации или у любого поставщика удостоверений. Для аутентификации пользователей с Azure AD B2C .
В разделе Redirect URI выберите Web , а затем введите
https://jwt.msв текстовом поле URL.URI перенаправления — это конечная точка, в которую пользователь отправляет сервер авторизации (в данном случае Azure AD B2C) после завершения взаимодействия с пользователем, и в которую после успешной авторизации отправляется токен доступа или код авторизации. В производственном приложении это обычно общедоступная конечная точка, в которой выполняется ваше приложение, например,
https: // contoso.com / auth-response. Для целей тестирования, таких как это руководство, вы можете установить его наhttps://jwt.ms, веб-приложение, принадлежащее Microsoft, которое отображает расшифрованное содержимое токена (содержимое токена никогда не покидает ваш браузер). Во время разработки приложения вы можете добавить конечную точку, где ваше приложение будет прослушивать локально, например,https: // localhost: 5000. Вы можете добавлять и изменять URI перенаправления в ваших зарегистрированных приложениях в любое время.Для перенаправления URI применяются следующие ограничения:
- Ответный URL должен начинаться со схемы
https. - URL ответа чувствителен к регистру. Его регистр должен совпадать с регистром пути URL вашего запущенного приложения. Например, если ваше приложение включает в свой путь
... / abc / response-oidc, не указывайте... / ABC / response-oidcв URL-адресе ответа. Поскольку веб-браузер обрабатывает пути как чувствительные к регистру, файлы cookie, связанные с... / abc / response-oidc, могут быть исключены, если они перенаправлены на несоответствующий регистру URL-адрес... / ABC / response-oidc.
- Ответный URL должен начинаться со схемы
В разделе Разрешения установите флажок Предоставить администратору разрешение openid и offline_access .
Выберите Зарегистрируйте .
После завершения регистрации приложения включите поток неявного предоставления:
- Под Управлять , выберите Аутентификация .
- В поле Неявное разрешение установите флажки Маркеры доступа и Идентификатор ID .
- Выберите Сохранить .
Войдите на портал Azure.
Выберите значок Каталог + подписка на панели инструментов портала, а затем выберите каталог, в котором содержится клиент Azure AD B2C.
На портале Azure найдите и выберите Azure AD B2C .
Выберите Приложения (Legacy) , а затем выберите Добавить .
Введите имя для приложения. Например, webapp1 .
Для Включить веб-приложение / веб-API и Разрешить неявный поток , выбрать Да .
Для ответного URL-адреса введите конечную точку, где Azure AD B2C должен возвращать все токены, запрошенные вашим приложением. Например, вы можете настроить его на локальное прослушивание
https: // localhost: 44316. Если вы еще не знаете номер порта, вы можете ввести значение заполнителя и изменить его позже.Для целей тестирования, таких как этот учебник, вы можете установить его на
https://jwt.ms, который отображает содержимое токена для проверки. Для этого учебного пособия установите ответный URL равнымhttps: // jwt.мс.К ответным URL применяются следующие ограничения:
- Ответный URL должен начинаться со схемы
https. - URL ответа чувствителен к регистру. Его регистр должен совпадать с регистром пути URL вашего запущенного приложения. Например, если ваше приложение включает в свой путь
... / abc / response-oidc, не указывайте... / ABC / response-oidcв URL-адресе ответа. Поскольку веб-браузер обрабатывает пути с учетом регистра, файлы cookie связаны с.../abc/response-oidcможет быть исключен, если перенаправлен на URL с несоответствием регистра... / ABC / response-oidc.
- Ответный URL должен начинаться со схемы
Выберите Создать , чтобы завершить регистрацию приложения.
Создать секрет клиента
Если ваше приложение обменивает код авторизации на токен доступа, вам необходимо создать секрет приложения.
- На странице Azure AD B2C — Регистрация приложений выберите созданное приложение, например, webapp1 .
- Под Управлять , выбрать Сертификаты и секреты .
- Выбрать Новый секрет клиента .
- Введите описание для секрета клиента в поле Описание . Например, clientsecret1 .
- В поле Срок действия выберите продолжительность, в течение которой секрет действителен, а затем выберите Добавить .
- Запишите значение секрета . . Это значение используется в качестве секрета приложения в коде приложения.
- На странице Azure AD B2C — Приложения выберите приложение, которое вы создали, например, webapp1 .
- Выберите Ключи , а затем выберите Создать ключ .
- Выберите Сохранить , чтобы просмотреть ключ. Запишите значение ключа приложения . Это значение используется в качестве секрета приложения в коде приложения.
Следующие шаги
В этой статье вы узнали, как:
- Зарегистрируйте веб-приложение
- Создать секрет клиента
Далее вы узнаете, как создавать пользовательские потоки, чтобы пользователи могли регистрироваться, входить в систему и управлять своими профилями.
,