При создании любого веб-приложения необходимо помнить о трех основных принципах.
С точки зрения клиента, приложение должно быть простым, эстетичным и решать большинство его проблем.
С точки зрения бизнеса веб-приложение должно соответствовать своему продукту и рынку.
С точки зрения инженера-программиста веб-приложение должно быть масштабируемым, функциональным и способным выдерживать высокие нагрузки трафика.
Все эти проблемы решаются в архитектуре веб-приложения. Мы рассмотрим основные концепции любого современного веб-приложения и объясним, как шаблоны архитектуры могут отличаться в зависимости от приложения, которое вы создаете.
Что такое архитектура веб-приложений?
Итак, что такое веб-приложение и чем оно отличается от веб-сайта?
Базовое определение веб-приложения - это программа, работающая в браузере. Это не веб-сайт, но грань между ними размыта. Чтобы отличить веб-приложение от веб-сайта, запомните эти три формальные характеристики. Веб-приложение:
Решает конкретную проблему, даже если это просто поиск некоторой информации
Оно такое же интерактивное, как настольное приложение
Имеет систему управления контентом
Под веб-сайтом традиционно понимают просто комбинацию статических страниц. Но сегодня большинство веб-сайтов состоят как из статических, так и из динамических страниц, что делает почти все современные веб-сайты - как вы уже догадались! - веб-приложениями. В этой статье мы будем использовать термины взаимозаменяемо.
Ваш компьютер, смартфон или любое другое устройство, с помощью которого вы просматриваете веб-страницы, называется клиентом. Другая половина веб-уравнения называется сервером, потому что он предоставляет вам данные, которые вы запрашиваете. Их общение называется моделью клиент-сервер, основной задачей которой является получение вашего запроса и доставка ответа.
Архитектура веб-приложения - это механизм, который определяет, как компоненты приложения взаимодействуют друг с другом. Или, другими словами, способ подключения клиента и сервера определяется архитектурой веб-приложения.
Веб-приложения разного размера и уровня сложности следуют одному и тому же архитектурному принципу, но детали могут различаться. Далее мы объясним, как работает базовый процесс запроса-ответа и какие компоненты составляют архитектуру.
Как работает веб-запрос?
Чтобы понять компоненты архитектуры веб-приложений, нам нужно понять, как они используются при выполнении самых основных действий - получении и ответе на веб-запрос. Ниже предлагаю ознакомиться со структурой работы веб-приложения.
Давайте посмотрим на примере testsite.com, чтобы понять механику обработки запросов.
Сначала вы посещаете testsite.com. Вы вводите URL-адрес, и когда вы нажимаете Enter, ваш браузер готовится распознать этот URL-адрес, потому что ему необходимо знать адрес сервера, на котором расположена страница. Таким образом, он отправляет ваш запрос в Центр доменных имен (DNS), хранилище доменных имен и их IP-адресов. Если вы уже посещали этот сайт из того же браузера, он извлечет адрес из кэша. Затем браузер отправляет запрос на найденный IP-адрес по протоколу HTTPS.
Далее веб-сервер обрабатывает запрос на стороне backend, это серверная часть приложения. Веб-сервер, на котором находится testsite.com, перехватывает запрос и отправляет его в хранилище, чтобы найти страницу и все данные, которые следуют за ней. Но его маршрут проходит через Business logic (BL - бизнес логика), также называемую логикой домена и логикой приложения. BL управляет доступом к каждой части данных и определяет этот рабочий процесс специально для каждого приложения. Когда BL обрабатывает запрос, он отправляет его в хранилище, чтобы найти искомые данные.
И, наконец, вы получаете свои данные. Ваш ответ возвращается к вам, и вы видите содержимое веб-страницы на своем дисплее. Графический интерфейс, который вы видите при прокрутке веб-сайта testsite.com или любого другого веб-сайта, называется frontend, внешним интерфейсом приложения - он отображает все компоненты UX и UI, чтобы пользователь мог получить доступ к информации, которую он искал.
Компоненты архитектуры веб-приложений
Большинство веб-приложений разрабатываются путем разделения основных функций на слои или уровни. Это позволяет легко заменять и обновлять каждый слой независимо друг от друга. Этот архитектурный шаблон называется многоуровневой или трехуровневой архитектурой.
Давайте разберем эту структуру.
Уровень представления (presentation layer)
Уровень представления доступен пользователям через браузер и состоит из компонентов пользовательского интерфейса и компонентов процесса пользовательского интерфейса, поддерживающих взаимодействие с системой. Он разработан с использованием трех основных технологий: HTML, CSS и JavaScript. В то время как HTML - это код, который определяет, что будет содержать ваш веб-сайт, CSS контролирует, как он будет выглядеть. JavaScript и его фреймворки делают ваш сайт интерактивным, реагирующим на действия пользователя. Разработчики используют фреймворки JavaScript, такие как Angular и React, чтобы сделать контент на странице динамичным.
Бизнес-уровень (business layer)
Этот уровень, также называемый бизнес-логикой, доменной логикой или прикладным уровнем, принимает пользовательские запросы от браузера, обрабатывает их и определяет маршруты, по которым будет осуществляться доступ к данным. Рабочие процессы, с помощью которых данные и запросы проходят через серверную часть, закодированы на бизнес-уровне. Например, если ваше приложение представляет собой веб-сайт бронирования отелей, бизнес-логика будет отвечать за последовательность событий, через которые пройдет путешественник при бронировании номера.
Хотя бизнес-правила могут быть проявлением бизнес-логики, это не одно и то же. Иногда бизнес-правила извлекаются и управляются отдельно с помощью системы управления бизнес-правилами.
Уровень хранения данных (persistence layer)
Представляет собой централизованное хранение, которое получает все запросы данных и предоставляет доступ к постоянному хранилищу приложения. Уровень персистентности тесно связан с бизнес-уровнем, поэтому логика знает, с какой базой данных обращаться.
Инфраструктура хранения данных включает в себя сервер и систему управления базами данных , программное обеспечение для связи с самой базой данных, приложения и пользовательские интерфейсы для получения данных и их анализа. Как правило, вы можете хранить свои данные либо на собственных аппаратных серверах, либо в облаке, используя услуги поставщика облачных технологий Huawei Cloud или других поставщиков услуг IaaS или PaaS.
Также есть компоненты, которые обычно присутствуют во всех веб-приложениях, но отделены от основных слоев:
Cross-cutting code. Этот компонент занимается другими задачами приложения, такими как связь, оперативное управление и безопасность. Он влияет на все части системы, но никогда не должен смешиваться с ними.
Third-party integrations. Платежные шлюзы, авторизация через социальные сети, системы бронирования на туристических веб-сайтах - все это интеграции, связанные с серверной частью приложения через API. Они позволяют вашему программному обеспечению получать данные из другого программного обеспечения и расширять ваши функциональные возможности без написания кода с нуля.
Давайте посмотрим, как трехуровневая архитектура реализована в различных типах веб-приложений.
Динамические веб-страницы, SPA и MPA
Frontend приложения может обслуживать как статический, так и динамический контент. В большинстве случаев это комбинация того и другого. Статические веб-страницы существуют на сервере такими, какие они есть, и содержат информацию, которая не меняется. Динамические веб-страницы меняют информацию каждый день или в ответ на запрос пользователя. Сочетание динамического и статического контента составляет веб-приложение. Простейшим примером веб-приложения с динамическим содержимым является одностраничное приложение SPA (Single page application).
Основная цель SPA дать возможность доступа ко всей информации с одной HTML страницы. Перенеся логику приложения на клиентскую сторону и используя серверную часть только как хранилище данных, разработчики могут ускорить работу сайта и снизить нагрузку на сервер. Внешний интерфейс, помимо HTML и CSS, написан на едином фреймворке, который динамически генерирует контент и передает его пользователю. Зависимости между компонентами жесткие. Это означает, что внесение изменений в один из элементов UX или UI требует переписывания всего frontend кода.
Поскольку SPA переносят логику на сторону клиента, они должны быть написаны с использованием сценариев на стороне клиента. Если вы используете технологии сценариев на стороне клиента, вы в основном создаете шаблоны, поэтому, когда пользователь запрашивает контент, сервер просто передает эти данные обратно в браузер, который отображает их в соответствии с шаблонами. Это значительно снижает нагрузку на сервер, в отличие от сценариев на стороне сервера. Основной технологией сценариев на стороне клиента является JavaScript. Наряду с многочисленными фреймворками этот язык позволяет создавать как небольшие, так и надежные приложения.
Давайте наложим все технологии на нашу трехуровневую архитектуру, о которой говорили ранее.
Когда роль сервера сводится к службам данных, это иногда называют архитектурой тонкого сервера.
Мы не можем говорить о SPA, не упомянув более традиционную и распространенную модель - многостраничные приложения MPA (multi page application).
В многостраничных приложениях для некоторых запросов контента требуется, чтобы с сервера была получена совершенно новая веб-страница. Это массивные приложения с многоуровневым пользовательским интерфейсом. Например, технология AJAX решает проблемы сложных приложений, передающих огромное количество данных между сервером и браузером, обновляя только отдельные элементы приложения. В то же время данный подход усложняет таблицу, поскольку ее сложнее разрабатывать по сравнению с SPA. Ниже представлена архитектура приложения MPA.
В отличие от клиентских сценариев SPA, традиционные приложения пишутся с использованием как клиентского, так и серверного языков. Сценарии на стороне сервера означают, что все операции выполняются на стороне сервера, поэтому, когда вы запрашиваете контент, он обрабатывает сценарий, извлекает данные из хранилища и выбирает контент для отображения. Cерверные языки программирования включают PHP, Java, Python, Ruby, C# и другие.
Есть еще один тип приложения, это:
Корпоративные приложения
Корпоративное приложение - это программное обеспечение с широкими возможностями настройки, разработанное специально для нужд конкретной организации. Обычно он имеет несколько бизнес-ориентированных инструментов, интегрированных в единый интерфейс. Корпоративные системы также напрямую подключены к существующему рабочему процессу компании. Они надежны, предоставляют доступ к большому количеству пользователей одновременно и используют общие интерфейсы с различными другими корпоративными инструментами.
Два основных отличия архитектуры корпоративных приложений от обычных веб-приложений - это добавление еще одного уровня к классическому шаблону так называемого сервисного уровня.
Сервисный уровень - это еще одна абстракция между представлением и бизнес-логикой. Это шлюз интеграции, который позволяет другому программному обеспечению получать доступ к вашей бизнес-логике и ресурсам без непосредственного взаимодействия с этими ресурсами. Он работает путем передачи сообщений через отдельный интерфейс и работает как API. Ниже на картинке добавили новый уровень.
Помимо дополнительного уровня, корпоративные приложения имеют доступ к источникам данных из других приложений в организации, что делает ее сетью программных решений, связанных API. Кроме того, существует больше групп пользователей, которые имеют доступ к различным функциональным компонентам. Это могут быть бизнес-партнеры, клиенты, администраторы и несколько групп персонала. Иногда уровни представления являются отдельными для всех из них, поэтому вы можете развернуть приложение как интрасеть или экстрасеть.
Надеюсь, эта статья прольет свет на закулисье создания современных веб-сайтов. В этой статье мы погрузились в сложную тему разработки программного обеспечения. Если вам это понравится, могу дальше публиковать материалы по теме, где есть некоторая экспертность.
Насчёт продолжения если интересно могу начать с JS. Типа что такое, с чем его едят и тп
