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

"Научный аспект №6-2024" - Информ. технологии

УДК 004.42

Добровольский Виктор Сергеевич – магистрант Балтийского государственного технического университета «Военмех» им. Д. Ф. Устинова.

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

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

Прошло уже 35 лет с момента, когда Всемирная паутина (World Wide Web, WWW) была запущена Тимом Бернерс-Ли в 1989 году. С тех пор Web претерпел значительные изменения, развиваясь от простых HTML-страниц до сложных интернет-приложений и сервисов. Основой для этого развития стала возможность обмена информацией между пользователями через HTTP протокол, который обеспечивает передачу данных между клиентом и сервером.

Hyper Text Transfer Protocol (HTTP) — это протокол, используемый для передачи гипертекстовых документов по сети. Протокол работает поверх транспортного слоя TCP/IP, который обеспечивает надежную доставку данных между клиентом и сервером. Он позволяет браузерам и серверам общаться друг с другом, обмениваясь данными в формате, понятном для веб-браузеров. Этот протокол стал основой для создания веб-сайтов и веб-приложений, позволяя пользователям получать доступ к информации из разных источников по всему миру. На рисунке 1 продемонстрировано взаимодействие пользователя с удаленным компьютером сети осуществимое с помощью протокола HTTP. Каждая доступная страница в Интернете имеет свой уникальный адрес, известный как URL, который позволяет пользователям находить и обращаться к конкретным ресурсам в сети. Концепция URI (Uniform Resource Identificator) — унифицированная нотация для адресации ресурсов, доступных по Сети. Общее описание может быть представлено следующим образом: scheme://host[:port]/path/.../[?query-string][#anchor][1]. Компоненты URI:

• scheme — схема обращения к ресурсу, обычно выражается в виде сетевого протокола, по которому доступен ресурс (http, file, mailto и др);
• host — идентификатор компьютера, на котором находится ресурс (может быть задан в виде IP-адреса или доменного имени);
• port — номер порта, по которому слушаются запросы на ресурс;
• path — путь до ресурса в иерархии директорий на компьютере, на котором находится ресурс;
• query-string — параметры запроса к ресурсу, задаются в формате название параметра = значение параметра и разделены знаком &;
• anchor — ссылка на часть документа, в документе могут быть установлены специальные метки (ярлыки), на которые можно сослаться.

Рисунок 1. Демонстрация работы HTTPS протокола

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

Статические сайты

Идея всемирной паутины (WWW) были максимально простыми и очевидными: предоставить инструменты для обмена информацией между людьми по всему миру.

В 1991 году был опубликован первый документ "HyperText Markup Language (HTML) Reference Manual" он описывал синтаксис и возможности первого стандарта разметки веб-страниц.

Первые сайты были простыми текстовыми страницами без графики и сложной функциональности. Они служили преимущественно для обмена информацией и распространения научных и исследовательских материалов. Один из самых ранних сайтов, который остается активным до сих пор, это сайт "info.cern.ch", который содержал информацию о World Wide Web и о том, как пользоваться этой новой технологией [2].

Скачок в развитии веба произошел в 1996, когда была опубликована первая спецификация CSS и она была рекомендована к использованию Консорциумом Всемирной паутины(W3C).

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

Интернет продолжал развиваться и вместе с ним рос объем данных, который требовалось обрабатывать и хранить на сайте. Появилась необходимость в более гибких инструментах для работы с данными, что привело к появлению серверных технологий. Они позволили обрабатывать и сохранять информацию в зависимости от поведения пользователя на сайтах. На рисунке 2 изображен сценарий, когда пользователь вводит URL веб-сайта в браузер и нажимает Enter, происходит процесс передачи данных по протокол HTTP, осуществляется GET запрос на сервер. Этот запрос адресован веб-серверу, который ответом присылает статический HTML-файл. «Статические сайт — это файл, состоящий из разметки HTML. При помощи CSS разработчики могут улучшать дизайн и положительный опыт работы у пользователя. Данные на таком сайт отображаются, но у пользователя нет возможности сохранить или изменить данные.».

Рисунок 2. Сценарий GET запроса

Динамические сайты

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

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

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

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

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

Схема динамического веб приложения продемонстрирована на рисунке 3, «общение» между клиентом и сервером осуществлялось посредством выполнения POST/GET запросов. На данной схеме сервер и веб страница являются одним приложением.

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

Рисунок 3. Схема динамического веб-приложения

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

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

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

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

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

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

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

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

Рисунок 4. Схема динамического веб приложения

Одностраничные приложения

SPA, или Single Page Application, представляет собой веб-приложение, которое работает на одной HTML-странице и обновляет её содержимое динамически без полной перезагрузки страницы. Это достигается за счёт асинхронных запросов к серверу, которые возвращают данные в формате JSON или XML, которые затем используются для обновления интерфейса с помощью JavaScript.

Первичную HTML-страницу SPA получает от веб-сервера, который может быть настроен для раздачи статических файлов, таких как HTML, CSS, JavaScript и изображения. Этот сервер, например, может быть настроен с использованием Nginx или Apache, которые способны обслуживать статические файлы и перенаправлять запросы на сервер приложения для обработки динамических запросов, предоставляя пользователю необходимые файлы через HTTP GET запросы.

Бэкенд приложение, в свою очередь, являются отдельным приложением, которое обрабатывает бизнес-логику, взаимодействует с базой данных и обрабатывает запросы от клиента. Оно может служить множеству клиентов, включая различные веб-приложения, мобильные приложения и даже сторонних партнеров, взаимодействующих через API. Как правило строго структурированные данные, например бизнес-логика, хранится в реляционных базах данных. В один момент с ростом «объема» проекта выявляется необходимость в хранении хаотичных, слабоструктурированных данных в виде документов. NOSQL базы данных документоориентированны, что позволяет разработчикам более гибко управлять данными, которые не укладываются в жесткую схему реляционных баз.

Сборщики, такие как Webpack, Rollup или Parcel. Они автоматизируют процесс компиляции и минификации исходного кода и других ресурсов (файлы css, изображения, аудиозаписи, шрифты и фоны) в единый бандл.

Бандл (англ. bundle — связка) — комплект программ или файлов, объединённых по общему признаку [3].

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

Рисунок 5. Схема SPA веб-приложения

Клиентский рендеринг (CSR)

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

Из названия можно предположить, что client-side rendering (CSR), подразумевает отрисовку контента в браузере пользователя. По сути, это изменённый метод для доставки контента целевой аудитории с использованием JavaScript [4].

Из-за того, что контент отрисовывается на стороне клиента. Такой подход идеален для современных фреймворков (React, Vue и другие) Браузеру отсылается практически пустой HTML-документ, в котором помимо стандартного шаблона есть один div блок c тегом root. а потом запускается скрипт, который рендерит приложение и вставляет в этот блок. Пользователь же будет видеть пустую страницу, пока JS-файл полностью не загрузится.

Серверный рендеринг (SSR)

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

По сравнению с клиентским одностраничным приложением (SPA) преимущества SSR заключаются прежде всего в следующем [5].

Быстрая загрузка приложения, это особенно заметно при медленном интернете или на медленных устройствах. Разметке, отрисованной на стороне сервера, не нужно ждать, пока загрузится и выполнится весь JavaScript, чтобы отобразиться, поэтому пользователь быстрее увидит полностью отрисованную страницу. Кроме того, при первом посещении страницы получение данных осуществляется на стороне сервера, который, скорее всего, имеет более быстрое соединение с базой данных, чем клиент. Это, как правило, приводит к улучшению показателей Core Web Vitals [6], повышению качества работы пользователей может иметь решающее значение для приложений, в которых время просмотра контента напрямую связано с коэффициентом конверсии [7].

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

Поисковые системы сразу видят полностью отрендеренную страницу, что значительно влияет на SEO.

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

Генерация статического сайта (SSG)

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

SSG сохраняет те же характеристики производительности, что и SSR-приложения: он обеспечивает отличные показатели "time-to-content". В то же время он дешевле и проще в развертывании, чем SSR-приложения, поскольку на выходе получается статический HTML и ресурсы. Ключевое слово здесь — статические: SSG можно применять только к страницам, потребляющим статические данные, т.е. данные, которые известны на момент сборки и не меняются между развертываниями. Каждый раз, когда данные меняются, требуется новое развертывание [8].

Прогрессивное веб-приложение (PWA)

Прогрессивные веб-приложения (PWA) — Основная идея заключается в том, чтобы вывести веб-приложение из контекста браузера и реализовать его на любом типе устройства, чтобы оно действовало и вело себя максимально похоже на нативное приложение. Это достигается за счет внедрения новых API в браузерные движки, а также интеграции с наиболее популярными операционными системами для настольных и мобильных устройств [9].

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

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

Таким образом можно выделить такие качества каждого типа веб приложения.

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

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

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

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

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

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

Список литературы

1. К. А. Кулаков, В. М. Димитров, Архитектуры и фреймворки веб-приложений // Издательство ПетрГУ – 2020 – Петрозаводск – С 10-15.
2. ГОСТ Р ИСО/МЭК 12207-2010. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. – Введ. 2012-03-01, М.: Стандартинформ, 2011.
3. Рендеринг на стороне сервера. // Vue.js URL: https://ru.vuejs.org/guide/scaling-up/ssr.html (дата обращения: 08.05.2024).
4. Рендеринг на стороне клиента. // Vue.js URL: https://ru.vuejs.org/guide/scaling-up/scr.html (дата обращения: 08.05.2024).
5. Оптимизация качества взаимодействия с пользователем // WEB.DEV URL: https://web.dev/articles/vitals?hl=ru (дата обращения: 08.05.2024).
6. DOM — JavaScript — Дока. // Doka. URL: https://doka.guide/tools/dom/ (дата обращения: 08.05.2024).
7. ГОСТ Р ИСО/МЭК 25010-2015 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов. Введ. 2015-05-29. М., 2015, 30с.
8. Виды веб приложений Дока. // Doka. URL: https://doka.guide/tools/web-app-types/ (дата обращения: 08.05.2024).
9. Знакомство с single-spa // SPA URL: https://ru.single spa.js.org/docs/getting-started-overview (дата обращения: 08.05.2024).
10. Статические сайты и их генерация // URL: https://blog.logrocket.com/static-site-generation-with-react-from-scratch/ (дата обращения: 08.05.2024).