Веб приложение это кратко

Обновлено: 04.07.2024

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

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

Любое веб-приложение, если оно работает в браузере, работает на 3 основных технологиях: HTML, CSS и JS. Ещё есть WASM, но о нём в этой статье мы говорить не будем.

Все приложения, которыми вы пользуетесь в браузере: GoogleDocs, Notion, Яндекс.Карты, Spotify, YouTube — сделаны с помощью этих технологий.

Но любое сложное приложение — это не только картинка в браузере, это ещё и данные, которые пользователи используют или создают. Эти данные нужно уметь хранить, обрабатывать и выводить.

Хранением и обработкой данных обычно занимается сервер или бэкенд.

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

А архитектура, в которой участвуют сервер (бэкенд) и клиент (браузер, фронтенд) называется клиент-серверной.

Клиент-серверная архитектура

Начнём с самого понятия.

Архитектура — это описание системы на самом высоком уровне.

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

Самый канонический вид такой архитектуры таков:

схема клиент-серверной архитектуры

Клиент

Клиент обращается с запросами к серверу.

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

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

Роль клиента для пользователя в том, чтобы представить данные в удобном виде и предоставить механизмы для их обновления.

Для веба клиент почти всегда браузер.

Сервер

Сервер принимает запросы от клиента.

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

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

База данных

База данных (БД) — это хранилище всей пользовательской и служебной информации.

Её роль в том, чтобы обеспечивать быстрый и бесперебойный доступ к этой информации и собственно хранение.

Пример

Возьмём Твиттер. В этом приложении клиентом будет выступать весь его фронтенд: HTML-страницы, CSS-стили, JS-скрипты для взаимодействия пользователя с UI.

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

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

Развитие веб-приложений

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

Первые приложения

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

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

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

AJAX (Asynchronous JavaScript and XML) — общение между клиентом и сервером без перезагрузки страницы.

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

Сервер обработает запрос, достанет нужные данные, отсортирует их и отправит клиенту готовый кусок интерфейса, который клиент уже вставит в документ.

Заметьте, что мы всё ещё не передаём данные в чистом виде. Сейчас на клиенте мы принимаем кусок HTML-разметки, который потом встраиваем в нужное место в документе.

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

Современные приложения

В современных приложениях между клиентом и сервером общение строится именно на данных, а не на отрендеренных кусках разметки. Чаще всего для такого общения выбирают JSON.

Сейчас большая часть приложений работает так:

Плюсов такого общения (когда передаются только данные) несколько:

  • Сервер и клиент становятся независимыми друг от друга. Сервер может ничего не знать об устройстве страниц, ему достаточно лишь уметь работать с БД и обрабатывать данные (первичная отрисовка может быть сделана самим сервером с помощью SSR).
  • Количество информации, которое приходится передавать и принимать, меньше — а это уменьшает объём трафика.
  • Логика приложения на сервере может быть проще, потому он и клиент становятся менее зависимы друг от друга в плане формата данных.

Разделение ответственности

Такое общение между сервером и клиентом очень напоминает паттерн MVC.

MVC (Model-View-Controller) — структура приложения, в которой за данные, их обработку и их вывод отвечают три разных сущности.

  • Модель (model) отвечает за данные и их структуру.
  • Представление (view) — за их отображение.
  • Контроллер (controller) — за их обработку.

схема паттерна Model View Controller

Если попробовать сравнить классическую клиент-серверную архитектуру с MVC, то можно сравнить БД с моделью, сервер с контроллером, а клиент с представлением.

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

MVC на клиенте

Возьмём для примера Notion. Его веб-версия работает прямо в браузере, однако это полноценный текстовый редактор.

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

Одной из таких практик как раз является разделение данных и представления.

Как бы текстовый редактор сделали 20 лет назад

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

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

Текстовые редакторы сейчас

. чаще всего делают, разделяя данные от их представления.

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

  1. Это делает работу с данными сильно проще — можно выгрузить документ в разных форматах: . md , . html , . txt .
  2. С таким представлением проще работать в самом коде — отчего и сам код становится проще для понимания.
  3. Его удобнее хранить в памяти, как состояние приложения.

Состояние приложения

Текстовый редактор из нашего примера выше — это приложение с состоянием.

Состояние приложения — это все данные этого приложения на текущий момент.

В случае с текстовым редактором — это весь текст, который пользователь ввёл, а также результаты преобразований над этим текстом.

Разумеется, текстовые редакторы не единственный вид таких приложений. Любое приложение, которое хранит что-то перед отправкой (или даже без отправки) на сервер — это приложение с состоянием.

Плюсы в выделении состояния те же:

  • данные перестают зависеть от того, как мы хотим их представлять;
  • их проще обрабатывать и хранить;
  • представление проще менять.

Как правило, состояние в приложениях на JS — это какой-то объект или массив объектов в памяти.

Такой вид состояния не только удобен в использовании внутри приложения, но ещё и прост в сохранении с помощью JSON.

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

Сейчас есть много подходов и инструментов для управления состоянием. Из самых популярных можно назвать: Redux (и основанные на его подходе Vuex, NgRx), MobX, Overmind.

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

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

Состояние из примера выше в формате JSON выглядело бы так:

Запросы и ответы

Как мы помним, клиент-серверная архитектура строится на запросах и ответах. Разберёмся, что использует браузер, чтобы послать на сервер какой-то запрос.

fetch

На уровне приложения мы используем встроенное браузерное API, а именно — fetch . Это глобальный метод для отправки запросов.

В примере выше, чтобы сохранить состояние на сервере, мы бы использовали его примерно так:

Здесь мы отправляем запрос по адресу / api / save - text с телом JSON . stringify ( State ) . Адрес и тело (данные) — понятно, а что такое method : "POST" ?

Они указывают, какое действие мы хотим выполнить. В примере method : "POST" сообщит серверу, что мы хотим создать новый ресурс и сохранить в него содержимое body .

Если бы мы хотели получить какой-то ресурс, мы бы использовали GET . Для редактирования — PATCH , для замены — PUT , а для удаления — DELETE .

Описывать сам протокол мы не будем, это большая спецификация, для которой бы понадобилась отдельная статья.

REST (Representational State Transfer) — стиль общения компонентов, при котором все необходимые данные указываются в параметрах запроса.

Отличительная особенность этого стиля — это стиль построения адресов и выбор метода.

Как мы можем видеть, основа адреса не меняется, а желаемое действие выражается методом.

Сейчас именно на основе REST работает множество сервисов и приложений.

Развитие веба и объёмы данных

С развитием веба и интернета в целом пришло время больших объёмов данных. Картинки по 10 МБ уже никого не удивляют.

Вместе с большими объёмами пришли и проблемы с их передачей, потому что трафик поначалу был очень дорогим. Он и сейчас в некоторых случаях не дешёвый.

Кэширование

Отчасти решением стало кэширование ресурсов. С картинками это помогло — картинки из кэша не съедают трафик, потому что не гонятся по сети.

Со скриптами и стилями — помогло отчасти, потому что объём лишь одна часть проблемы. Вторая часть — это парсинг и исполнение. Особенно остро эта проблема стоит со скриптами, потому что скрипты весом в 10 МБ уже тоже не редкость.

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

Код-сплиттинг

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

Middle-end

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

REST известен не только своим удобством, но и (иногда) чрезмерной избыточностью.

Проблема в том, что REST система проектируется так, чтобы как можно реже меняться при изменении клиента. Из-за этого данные, отдаваемые в ответ, могут содержать детали, которые клиентом использоваться не будут.

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

Поэтому сейчас сообщество смотрит в сторону некого мидл-энда — такого слоя между клиентом и сервером (или сразу БД), который бы удалял всё лишнее, что клиенту не требуется, и отдавал бы лишь необходимые данные, таким образом сократив объём. Как, например, GraphQL.

Заключение

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

Мы узнали о клиент-серверной архитектуре, разделении данных от представления и том, как они используются в современных приложениях. Также мы рассмотрели, что такое состояние приложения и поговорили о REST, как одном из распространённых способов построения API.

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

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

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

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

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

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

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

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

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

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

  1. Работают на нескольких платформах, независимо от ОС или устройства.
  2. Все пользователи получают доступ к одной и той же версии проекта, что устраняет любые проблемы совместимости.
  3. Не устанавливаются на жесткий диск, что устраняет ограничения по месту.
  4. Серверная часть приложения находится на вашей стороне, поэтому пользователи не могут взломать лицензионное ограничение, что предотвращает компьютерное пиратство.
  5. Сокращают расходы как для бизнеса, так и для конечного пользователя, поскольку требуется меньше поддержки и обслуживания, а также снижает требования к компьютеру или смартфону конечного пользователя.

Вывод

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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


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

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 отсутствует.

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

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

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

О компании Trio Motors

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

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

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


Конечному пользователю бывает сложно понять разницу между сайтом и веб-приложением. Он просто вводит URL в адресной строке браузера (переходит по ссылке) — и — бум! — вот он результат.

А для пользователя важно как раз получить то, что хотелось. Если это удалось сделать, больше пользователя ничто не волнует.

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

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

Что такое сайт?


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

Сайты бывают самые разные:

  • сайты знакомств
  • сайты-блоги
  • сайты сообществ
  • образовательные сайты
  • поисковики и т.д.

Примеры сайтов: Википедия, Google, Amazon, Craigslist.

Отличительные черты сайтов

  • Сайт дружественен к пользователю
  • На нем легко найти нужную информацию при помощи поисковика
  • Он отображает качественный контент
  • Имеет простую и доступную навигацию.

Зачем вам может понадобиться сайт

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

Что такое веб-приложение?


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

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

Примеры популярных веб-приложений: Twitter, Facebook, Gmail, Adobe CC, YouTube.

Отличительные черты веб-приложений

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

Зачем вам может понадобиться веб-приложение

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

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


1. Взаимодействие с пользователем

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

2. Аутентификация

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

3. Решаемые задачи и сложность

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

4. Для кого создается

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

5. Деплоймент

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

Заключение

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

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

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

Веб-приложения стали широко популярными в конце 1990-х — начале 2000-х годов.

Содержание

Технические особенности

Существенное преимущество построения Web приложений для поддержки стандартных функций браузера заключается в том, что функции должны выполняться независимо от операционной системы данного клиента. Вместо того чтобы писать различные версии для Microsoft Windows, Mac OS X, GNU/Linux и других операционных систем, приложение создается один раз для произвольно выбранной платформы и на ней разворачивается. Однако различная реализация HTML, CSS, DOM и других спецификаций в браузерах может вызвать проблемы при разработке веб-приложений и последующей поддержке. Кроме того, возможность пользователя настраивать многие параметры браузера (например, размер шрифта, цвета, отключение поддержки сценариев) может препятствовать корректной работе приложения.

Другой (менее универсальный) подход заключается в использовании Adobe Flash, Silverlight или Java-апплетов для полной или частичной реализации пользовательского интерфейса. Поскольку большинство браузеров поддерживает эти технологии (как правило, с помощью плагинов), Flash- или Java-приложения могут выполняться с легкостью. Так как они предоставляют программисту больший контроль над интерфейсом, они способны обходить многие несовместимости в конфигурациях браузеров, хотя несовместимость между Java или Flash реализациями на стороне клиента может приводить к различным осложнениям.

Устройство веб-приложений

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

Само веб-приложение может выступать в качестве клиента других служб, например, базы данных или другого веб-приложения, расположенного на другом сервере. Ярким примером веб-приложения является система управления содержимым статей Википедии: множество её участников могут принимать участие в создании сетевой энциклопедии, используя для этого браузеры своих операционных систем (будь то Microsoft Windows, GNU/Linux или любая другая операционная система) и не загружая дополнительных исполняемых модулей для работы с базой данных статей.

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

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

Читайте также: