Что такое web приложение

Общие сведения о веб-приложениях

Пользовательский интерфейс в Dreamweaver СС и более поздних версиях стал проще. В результате этого некоторые функции, описанные в этой статье, могут отсутствовать в Dreamweaver CC и более поздних версиях. Дополнительные сведения см. в этой статье.

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

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

Типичное применение веб-приложений

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

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

Данный вид веб-приложений позволяет осуществлять поиск в содержимом, упорядочивать содержимое и перемещаться по нему удобным для посетителей способом. Примерами таких приложений могут служить внутренние сети компаний — Microsoft MSDN (www.msdn.microsoft.com) и Amazon.com (www.amazon.com).

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

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

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

Веб-приложение освобождает веб-дизайнера от рутинной работы постоянного обновления HTML-страниц сайта. Поставщики содержимого, например редакторы новостей, отвечают за наличие свежего материала, а веб-приложение следит за автоматическим обновлением сайта. В качестве примера можно привести веб-версию журнала «The Economist» (www.economist.com) и службы новостей CNN (www.cnn.com).

Пример веб-приложения

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

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

В ответ на это Светлана предложила создать веб-приложение, которое будет решать следующие задачи.

Данные о своих спортивных достижениях сотрудники будут вносить в простую HTML-форму.

Полученные данные будут сохраняться в базе данных.

Начисление баллов будет выполняться на основе полученных данных.

Каждый сотрудник может получить данные о своих результатах.

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

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

Принципы работы веб-приложений

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

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

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

Обработка статических веб-страниц

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

Веб-сервер — это программное обеспечение, которое предоставляет веб-страницы в ответ на запросы веб-браузеров. Обычно запрос страницы создается при щелчке ссылки на веб-странице, выборе закладки в браузере либо вводе URL-адреса в адресной строке браузера.

Окончательное содержимое статической веб-страницы определяется разработчиком и остается неизменным в процессе запроса страницы. Пример:

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

Если подходить строго, «статическая» страница может на самом деле таковой не являться. Например, замещающее изображение либо Flash-содержимое (в виде SWF-файла) позволяет «оживить» статическую страницу. Однако в данном контексте страница является статической, поскольку отсылается браузеру без изменений.

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

A. Веб-браузер запрашивает статическую страницу. B. Веб-сервер находит страницу. C. Веб-сервер отправляет страницу запросившему ее браузеру.

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

Обработка динамических страниц

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

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

A. Веб-браузер запрашивает динамическую страницу. B. Веб-сервер находит страницу и передает ее серверу приложений. C. Сервер приложений просматривает страницу на наличие инструкций и выполняет ее создание. D. Сервер приложений возвращает подготовленную страницу на веб-сервер. E. Веб-сервер отправляет подготовленную страницу запросившему ее браузеру.

Доступ к базе данных

Сервер приложений предоставляет возможность использовать такие ресурсы сервера, как базы данных. Например, динамическая страница может содержать программные инструкции для сервера приложений, следуя которым серверу необходимо получить определенные данные из базы данных и поместить их в HTML-код страницы. Подробнее см. здесь: www.adobe.com/go/learn_dw_dbguide_ru.

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

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

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

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

Ниже приводится пример простого запроса к базе данных на языке SQL.

С помощью этой инструкции формируется набор записей из трех столбцов, содержащих фамилию, имя и набранные баллы всех сотрудников, сведения о которых хранятся в базе данных. Подробнее см. здесь: www.adobe.com/go/learn_dw_sqlprimer_ru.

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

A. Веб-браузер запрашивает динамическую страницу. B. Веб-сервер находит страницу и передает ее серверу приложений. C. Сервер приложений просматривает страницу на наличие инструкций и выполняет ее подготовку. D. Сервер приложений отправляет запрос драйверу базы данных. E. Драйвер выполняет запрос в базе данных. F. Драйверу возвращается набор записей. G. Драйвер передает набор записей серверу приложений. H. Сервер приложений вставляет данные в страницу и передает страницу веб-серверу. I. Веб-сервер отправляет подготовленную страницу запросившему ее браузеру.

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

Для создания малобюджетных приложений можно использовать файловую базу данных, например базу данных, созданную с помощью Microsoft Access. Если планируется создание надежных корпоративных приложений, рекомендуется использовать серверную базу данных, например, на основе серверов Microsoft SQL Server, Oracle 9i или MySQL.

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

Разработка динамических страниц

Процесс разработки динамических страниц состоит из написания базового HTML-кода и последующего создания серверных сценариев или тегов HTML-страницы, с помощью которых страница становится динамической. Если взглянуть на окончательный код, видно, что язык сценариев встроен в HTML-код страницы. Соответственно, такие языки сценариев называют языками, встроенными в HTML. В следующем примере используется язык разметки ColdFusion Markup Language (CFML).

Примечание. В Dreamweaver CC и более поздних версиях поддержка CFML отсутствует.

Встроенные в данную страницу инструкции выполняют следующие действия.

Значение «Sales» помещается в HTML-код.

Сервер приложений возвращает следующую страницу на веб-сервер:

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

О компании Trio Motors

Компания Trio Motors является одним из ведущих производителей автомобилей.

Не забудьте посетить страницу нашего отдела продаж.

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

Источник

Что такое веб-приложение: определение и ключевые преимущества

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

Наглядные примеры

К примеру, возьмем Microsoft Office. Это приложение, которое устанавливается на ваш компьютер. А теперь посмотрим на его аналог — Google Docs. Это тоже программа, только находится она на удаленном сервере (не на вашем ПК), а доступ к ней возможен только через Интернет. Поэтому Google Docs относится к веб-приложениям.

Еще один пример. Adobe Photoshop — приложение для обработки изображений. Для работы с ним его нужно скачать с сайта и установить на ваш компьютер. А вот у похожего на фотошоп сервиса Figma есть веб-приложение, которое работает через Интернет, не требует скачивания и установки.

Веб-приложение — это программное обеспечение, которое хранится на удаленном сервере и доступно через Интернет. Собственно такой подход принято называть «Программное обеспечение как услуга» (SaaS).

Отличия веб-приложений от сайтов и мобильных приложений

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

Мобильные приложения разрабатываются под какую-то платформу (Android или iOS) и требуют установки на устройство. А веб-приложения доступны пользователю без скачивания, вне зависимости от устройства и браузера пользователя.

Ключевые преимущества веб-приложений

Вывод

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

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

Источник

Web Apps: быстро, дёшево, круто

Каждый Web App (веб-апп) — это маленькое и весёлое фронтенд-приключение.
Однажды в iFunny мы устроили «веб-апп марафон», развлекли миллионы пользователей и попутно заработали много денег. А теперь готовы рассказать, как же это всё было.

Для начала представлюсь. Меня зовут Антон, я тимлид фронтенд-команды FunCorp.
И в этой статье я поделюсь опытом разработки интерактивных веб-приложений на базе мобильного WebView.

Web App View

WebView — это встроенный в мобильное приложение браузер.
А если есть браузер, значит, есть и обширные возможности HTML5, JS, CSS.
Это в теории. А как же на самом деле?

А на самом деле нас интересовали и другие вопросы:

Web App #1: Hellowinner

В те времена команда состояла из двух человек и над всеми веб-аппами работал я один. С момента моего присоединения к команде прошло два месяца, поэтому с корабля я прямиком попал на «веб-апп бал».

Первое приложение было подготовлено к 31 октября — дню празднования Хеллоуина. С помощью мини-игры с двумя кнопками планировалось пощекотать нервы пользователям и вызвать вот такую реакцию:

Само же приложение выглядело вот так:

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

Технологический стек был простым:

Генератор Harp предоставил полную инфраструктуру из коробки, так что я написал код, сгенерировал статичный сайт с CSS, HTML, JS, положил всё это дело на CDN, завернул в WebView и радовался. И было чему: первый опыт с веб-приложениями дал такой пик посещаемости, что позже каждый product-менеджер считал своим долгом придумать что-то интересное.

Web App #2: Putin vs Trump

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

В следующем веб-аппе было решено проводить опросы пользователей. Разумеется, в любимом формате — на скользкие и горячие темы. Первый опрос назывался President you want, и в нём нужно было выбрать Путина или Трампа.

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

В качестве базы данных я использовал MongoDB: API для мобильных клиентов iFunny крутился именно на данной системе, был готовый кластер, и выбор был очевиден. Express.js был выбран в качестве серверного фреймворка. Все тот же Jade (Pug) в качестве шаблонизатора, LESS в качестве препроцессора и сборка статики с помощью Gulp.

В первые часы после запуска нового приложения проголосовало свыше миллиона пользователей. И тут произошел курьёз: сумма процентов перевалила за 100%. Не 146% конечно, рядом.

Вместо того чтобы использовать стандартный инкремент из базы данных, я использовал банальное «текущее значение = текущее значение + 1». А про такое понятие, как конкурентность запросов, узнал вообще только в продакшене. Ну да, пустили слона в посудную лавку.

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

Тот самый опрос, исправленный:

Web App #3: Booby Bird

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

Парень — молодец, постарался на славу:

Мой оптимизм окончательно иссяк после того, как приложение наотрез отказалось запускаться на боевом домене. В итоге, я перенес код на уже проверенный Express.js и, насколько смог, внес заплатки в обфусцированный клиентский код. Игра ожила. Уже тогда было понятно, что конструкция хрупкая и держится на честном слове.

В конце игры был рейтинг лучших игроков и, разумеется, его сломали через 10 минут после релиза. Пользователи раскопали ссылку на сохранение результатов и массово принялись менять в ней значения. Я выпустил обновление, в котором персонализировал ссылку с помощью JWT-токена, и массовое окучивание топа закончилось.

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

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

Web App #4: Holiday Giveaway

На один из самых любимых американцами праздников — Рождество — была устроена лотерея, в которой разыгрывались приставки, подарочные карты, камеры, футболки и ряд других приятностей. Всего было проведено 4 розыгрыша, каждый в строго определённое время. После проведения очередного розыгрыша открывалась регистрация на следующий.

«Под капотом» были все те же Express.js, Jade (Pug), LESS. Ожидался большой пик посещаемости, и в качестве базы данных я использовал отдельный кластер MongoDB. И даже провел нагрузочное тестирование, чтобы вот в этот раз все точно получилось как надо. Ну, вы понимаете.

Веб-апп показал отличные результаты: около 3 миллионов участников уже в первом туре. Вот только вместе с успехом пришли и трудности.

Сначала проблема возникла в связке NGINX и PM2, который использовался для управления инстансами приложения. Мне искренне было страшно, я вообще не понимал, что делать: HTML5, CSS, JS, а тут какие-то таймвейты в сети, озадаченные DevOps-инженеры и молчаливый требовательный взгляд технического директора. Спустя некоторое время проблема была устранена, а до следующего розыгрыша призов был запас времени. Я наивно начал полагать, что теперь всё хорошо, отмучился.

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

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

Такие жертвы были оправданы: спустя 24 часа у веб-аппа было более 12 миллионов просмотров, тысячи комментариев и большой шум по социальным сетям. Пользователи сильно взбудоражились: им определённо понравилось приложение. Да и мне понравилось, что скрывать.

Минусы и плюсы веб-аппов

За период с сентября по декабрь было сделано 6 веб-аппов. И каждый из них дал хорошие результаты. «Веб-апп марафон» позволил ответить на все интересующие вопросы, в том числе на самый важный: да, это определённо стоящая тема, чтобы продолжать ей заниматься.

Сейчас разработка веб-аппов уже поставлена на поток: за прошедший 2017 их было 94, а по количеству сессий что-то около 101 миллиона. Кстати, большую часть можно посмотреть по ссылке.

Я же, в свою очередь, понял кое-что про работу в продуктовой компании.

Когда решался вопрос со сменой работы, я морально готовился к тому, что делать один продукт — это скучно, и мне скорее всего предстоит «пилить сайт» ближайшие 2 года. Когда же пришлось делать веб-аппы, обжигаться инкрементом, видеть больше 10К реквестов в секунду, руками ночью запускать скрипты — понял, как ошибался. Мне действительно приходилось «пилить продукт», правда, каждую неделю — новый. А это отличный фан и приличное развитие навыков.

К слову, те «ближайшие 2 года» мне всё-таки предстояло «пилить сайт», только в качестве новоиспеченного лида формировавшейся с нуля фронтенд-команды. Этот опыт повеселей веб-аппов будет. О нём расскажу в следующей статье.

Источник