Что такое архитектура веб-приложений? Разрушение веб-приложения

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

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

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

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

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

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

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

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

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

Почему важна архитектура веб-приложений?

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

Однако выбор правильной архитектуры еще больше усиливает эти преимущества.

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

Легкая адаптация к потребностям бизнеса

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

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

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

Организованное развитие

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

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

Лучшее управление кодовой базой

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

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

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

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

Повышенная безопасность

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

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

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

Как работает архитектура веб-приложений?

Прежде чем мы поговорим о том, как работает архитектура веб-приложений, важно понять, как работает простой веб-сайт:

1. Пользователь вводит URL-адрес вашего приложения в адресную строку браузера или щелкает ссылку.
2. Браузер просматривает URL-адрес на DNS-серверах и определяет IP-адрес вашего приложения.
3. Браузер отправляет HTTP-запрос вашему приложению.
4. Ваше приложение отвечает правильным содержимым (обычно это веб-страница).
5. Браузер отображает веб-страницу на экране.

Если бы вы копнули немного глубже, вот как веб-приложение обработало бы запрос:

1. Пользователь отправляет запрос в ваше приложение через интерфейс вашего внешнего интерфейса.
2. Если у вас настроен соответствующий кеш, приложение сначала проверит его, чтобы увидеть, есть ли в нем действительная запись, которую можно отправить обратно клиенту напрямую. Если да, кэшированное содержимое будет отправлено обратно, а запрос будет помечен как выполненный.
3. Если кэша нет, запрос перенаправляется балансировщику нагрузки.
4. Балансировщик нагрузки идентифицирует экземпляр сервера, доступный для обработки запроса, и перенаправляет его.
5. Экземпляр сервера обрабатывает запрос и при необходимости вызывает любые внешние API.
6. Как только результаты собраны в одном месте, сервер отправляет ответ балансировщику нагрузки.
7. Балансировщик нагрузки возвращает ответ шлюзу API, который, в свою очередь, отправляет его пользователю во внешнем клиенте. После этого запрос помечается как выполненный.

Типы архитектуры веб-приложений

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

Одностраничная архитектура

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

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

Плюсы архитектуры СПА

Некоторые из плюсов архитектуры SPA включают в себя:

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

Минусы архитектуры СПА

Вот несколько недостатков архитектуры SPA:

• SPA ограничивают гибкость гиперссылок и SEO.
• Первоначальный рендеринг обычно медленный.
• Навигация по приложению может быть неинтуитивной.

Прогрессивная архитектура веб-приложений

Архитектура прогрессивного веб-приложения (PWA) строится на основе одностраничной архитектуры, предоставляя автономные возможности для вашего веб-приложения. Такие технологии, как Capacitor и Ionic, используются для создания PWA, которые могут предоставить пользователям одинаковый опыт работы на разных платформах.

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

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

Плюсы архитектуры PWA

Архитектура PWA имеет много преимуществ, в том числе:

• Приложения работают очень плавно и обеспечивают кроссплатформенную совместимость.
• Масштабируемость проста.
• Разработчикам доступны автономный доступ и собственные API-интерфейсы устройств, такие как фоновые рабочие процессы и push-уведомления.

Минусы архитектуры PWA

Некоторые из недостатков архитектуры PWA могут включать:

• Существует ограниченная поддержка управления ссылками и SEO.
• Отправка обновлений в автономные PWA более сложна, чем в нативных приложениях.
• Поддержка PWA в веб-браузерах и операционных системах ограничена.

Архитектура с визуализацией на стороне сервера

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

Приложения SSR очень популярны среди блогов и сайтов электронной коммерции. Это потому, что они делают управление ссылками и SEO довольно простыми. Кроме того, первый рендеринг для приложений SSR выполняется довольно быстро, поскольку клиенту не требуется обрабатывать какой-либо код JS для рендеринга экранов.

Плюсы архитектуры SSR

Некоторые плюсы архитектуры SSR перечислены ниже:

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

Минусы архитектуры SSR

Несколько недостатков использования архитектуры SSR включают в себя:

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

Предварительно визуализированная архитектура приложений

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

Предварительно обработанные веб-приложения отлично подходят для создания статического контента, такого как блоги или сведения о продуктах, которые не меняются часто. Вы также можете использовать шаблоны, чтобы упростить дизайн веб-страницы. Однако с такой архитектурой практически невозможно создавать динамические веб-приложения. Если вы хотите создать страницу поиска, которая принимает запрос на своем пути (что-то вроде https://myapp.com/search/foo+bar ), вы находитесь не в том месте.

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

Плюсы предварительно визуализированной архитектуры

Вот несколько основных преимуществ архитектуры приложений с предварительной визуализацией:

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

Минусы предварительно визуализированной архитектуры

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

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

Изоморфная архитектура приложений

Изоморфные приложения представляют собой смесь приложений, отображаемых на стороне сервера, и SPA. Это означает, что такие приложения сначала отображаются на сервере как обычное приложение, отображаемое на стороне сервера. Как только они получены клиентом, приложение увлажняет себя и прикрепляет виртуальный DOM для более быстрой и эффективной обработки клиента. По сути, это превращает приложение в одностраничное приложение.

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

Плюсы изоморфной архитектуры

Вот лишь некоторые из преимуществ использования изоморфной архитектуры приложений:

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

Минусы изоморфной архитектуры

Вот некоторые из недостатков изоморфной архитектуры приложений:

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

Сервис-Ориентированная Архитектура

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

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

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

К основным преимуществам сервис-ориентированной архитектуры относятся:

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

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

Вот список потенциальных недостатков использования сервис-ориентированной архитектуры:

• Приложения SOA по-прежнему не обладают 100-процентной гибкостью, поскольку размер и объем каждой службы не фиксированы. Могут быть службы размером с корпоративные приложения, которые сложно поддерживать.
• Совместное использование компонентов вводит зависимости между службами.

Архитектура микросервисов

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

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

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

Некоторые плюсы микросервисной архитектуры включают в себя:

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

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

Недостатком микросервисной архитектуры могут быть:

• Для небольших проектов архитектура микросервисов может потребовать слишком много усилий для обслуживания.

Бессерверная архитектура

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

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

Плюсы бессерверной архитектуры

Вот основные преимущества бессерверной архитектуры:

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

Минусы бессерверной архитектуры

Ниже приведены некоторые недостатки бессерверной архитектуры:

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

Уровни архитектуры веб-приложений

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

Уровень представления

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

Для создания этого уровня используются три фундаментальные технологии: HTML, CSS и JavaScript. HTML формирует ваш внешний интерфейс, CSS стилизует его, а JS наполняет его жизнью (т. е. контролирует его поведение, когда пользователи взаимодействуют с ним). Помимо этих трех технологий, вы можете использовать любой фреймворк, чтобы упростить разработку. Некоторые распространенные интерфейсные фреймворки включают Laravel, React, NextJS, Vue, GatsbyJS и т. д.

Бизнес-уровень

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

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

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

Слой сохранения

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

Этот уровень обычно состоит из сервера базы данных. Вы можете настроить этот уровень самостоятельно, предоставив базу данных и сервер базы данных в своей локальной инфраструктуре, или выбрать удаленное/управляемое решение от одного из ведущих поставщиков облачной инфраструктуры, таких как AWS, GCP, Microsoft Azure и т. д.

Компоненты веб-приложений

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

Серверные компоненты

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

DNS и маршрутизация

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

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

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

Хранилище данных

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

• Базы данных: базы данных используются для хранения данных для быстрого доступа. Обычно они поддерживают хранение небольшого объема данных, к которым регулярно обращается ваше приложение.
• Хранилища данных: Хранилища данных предназначены для сохранения исторических данных. Обычно они не очень часто нужны в приложении, но регулярно обрабатываются для получения бизнес-аналитики.

Кэширование

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

• Кэширование данных. Кэширование данных позволяет вашему приложению легко и быстро получать доступ к регулярно используемым данным, которые редко меняются. Такие технологии, как Redis и Memcache, позволяют кэшировать данные, чтобы сэкономить на дорогостоящих запросах к базе данных, просто чтобы снова и снова извлекать одни и те же данные.
• Кэширование веб-страниц: CDN (сеть доставки контента) кэширует веб-страницы так же, как Redis кэширует данные. Подобно тому, как кэшируются только те данные, которые не часто меняются, обычно рекомендуется кэшировать только статические веб-страницы. Для веб-приложений, отображаемых на стороне сервера, кэширование не приносит особой пользы, поскольку их содержимое должно быть высокодинамичным.

Работа и услуги

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

Задания CRON — это те, которые выполняются в течение фиксированного периода времени снова и снова. Эти задания запланированы на серверной части для автоматического запуска процедур обслуживания в установленное время. Некоторые распространенные примеры использования для них включают удаление дубликатов / старых записей из базы данных, отправку электронных писем с напоминаниями клиентам и т. д.

Клиентские компоненты

Компоненты на стороне клиента — это те компоненты, которые доступны вашим пользователям прямо или косвенно.

В этой категории в основном два типа компонентов.

Внешний пользовательский интерфейс

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

Внешний интерфейс в основном построен на трех популярных технологиях: HTML, CSS и JavaScript. Пользовательский интерфейс внешнего интерфейса может быть самостоятельным приложением с собственным жизненным циклом разработки программного обеспечения.

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

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

Бизнес-логика на стороне клиента

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

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

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

Модели компонентов веб-приложений

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

Один сервер, одна база данных

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

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

Однако эту модель не следует использовать в производстве, поскольку она крайне ненадежна. Проблема либо на сервере, либо в базе данных может привести к простою и потере бизнеса.

Несколько серверов, одна база данных

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

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

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

Несколько серверов, несколько баз данных

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

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

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

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

Службы приложений

Хотя три модели, упомянутые выше, хорошо подходят для монолитных приложений, существует еще одна модель для модульных приложений.

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

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

Среди немонолитных приложений эта модель довольно популярна. Устаревшие монолиты часто переходят на эту модель, чтобы использовать ее преимущества масштабируемости и модульности. Однако для управления приложениями, построенными по такой модели, часто требуются опытные разработчики, особенно опытные в DevOps и CI/CD.

Лучшие практики для архитектуры веб-приложений

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

1. Сделайте свой интерфейс отзывчивым

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

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

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

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

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

2. Отслеживайте время загрузки

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

По данным Portent, самые высокие показатели конверсии в электронной торговле происходят на страницах со временем загрузки от 0 до 2 секунд, а по данным Unbounce около 70% потребителей признают, что время загрузки страницы является важным фактором при их выборе для покупки у онлайн-продавца.

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

Однако с вебом все обстоит иначе.

Когда дело доходит до веб-приложений, ваши пользователи могут использовать что угодно, от новейших Apple Macbook M1 Pro до старых телефонов Blackberry и Nokia для просмотра вашего приложения. Иногда оптимизация внешнего интерфейса для такого широкого круга пользователей может быть сложной задачей.

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

Последние 5–10% производительности приложения обычно зависят от вашего варианта использования и могут быть исправлены только тем, кто хорошо знает ваше приложение и его технологии. Инвестировать в веб-производительность никогда не помешает!

3. Отдавайте предпочтение PWA везде, где это возможно

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

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

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

Поддерживайте чистоту и лаконичность своей кодовой базы

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

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

5. Автоматизируйте процессы CI/CD

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

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

Возможности безграничны, поэтому вам решать, как максимально эффективно использовать конвейеры CI/CD.

6. Включите функции безопасности

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

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

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

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

Вот краткое описание различных компонентов архитектуры:

• Blue boxes: App modules, which are possibly hosted as microservices or serverless functions.
• Red boxes: External BaaS components that provide for authentication and database.
• Green box: Routing component that moderates incoming requests from the client.
• Black box: Your client application exposed to the user.

The components of each of the colors above are vulnerable to various kinds of security threats. Here are a few security constructs you can put in place to minimize your exposure:

• App modules (blue): Since these are serverless functions, here are a few tips to strengthen their security:
  • Isolate app secrets and manage them independently of your source code
  • Maintain access controls through IAM services
  • Improve your testing efforts to also look for security threats through techniques such as SAST
• External services (red):
  • Set up access controls through their IAM modules to regulate access
  • Opt for API rate limiting
  • For services such as databases, set up finer control permissions, such as who can access the profiles' data, who can view the users' data, and more. Many services, like Firebase, provide a detailed set of such rules.
• Routing component (green):
  • Like all other components, implement access controls
  • Set up authorization
  • Double-check on standard best practices such as CORS
• Client:
  • Ensure that no app secrets are available to your client
  • Obfuscate your client code to minimize the chances of reverse engineering

While these are just a handful of suggestions, they stand to make the point that app security is complicated, and it's your responsibility to ensure that you're not leaving any loose ends for attackers to pull on. You cannot rely on a central security component to protect your business; app security is distributed across your app architecture.

7. Collect User Feedback

User feedback is a crucial tool to understand how well your app is doing in terms of business and technical performance. You can build the lightest and the smoothest app in the world, but if it doesn't let your users do what they expect, then all your efforts go down the drain.

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

The choice of feedback collection method is less important than taking action on the collected feedback. Customers love businesses that listen to their problems. Giants like McDonald's and Tesla do it, and that's one of the reasons why they continue to succeed in their markets.

Резюме

Интернет — это огромная площадка для множества приложений, каждое из которых разработано по-своему. Несколько типов архитектур позволяют веб-приложениям диверсифицироваться, развиваться и предлагать услуги пользователям по всему миру.
Learn how web application architecture affects the end-user experience and see best practices you can implement, all in this guide Click to Tweet
In this guide, we broke down the different models of web app architecture and showed you how crucial they are to an application's growth.

Is there a web app architecture that you really loved? Or is there another that you'd like to share with the world? Дайте нам знать в комментариях ниже!