Министерство образования и науки РФ Федеральное государственное бюджетное образовательное учреждение высшего образования «Смоленский государственный университет» Кафедра прикладной математики и информатики ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА ТЕХНОЛОГИИ РАЗРАБОТКИ ОДНОСТРАНИЧНЫХ WEBПРИЛОЖЕНИЙ Выполнил: студент 4 курса физико-математического факультета направление подготовки 01.03.02 Прикладная математика и информатика (профиль «Математическое и информационное моделирование») НИКУЛИН Сергей Александрович Научный руководитель: Кандидат физико-математических наук, доцент ЕМЕЛЬЧЕНКОВ Евгений Петрович Смоленск 2021 ОГЛАВЛЕНИЕ ВВЕДЕНИЕ .............................................................................................................. 3 ГЛАВА 1. ОСНОВНЫЕ ПОЛОЖЕНИЯ SPA. ..................................................... 5 1.1 История возникновения одностраничных web приложений. .................... 5 1.2 Основные преимущества и недостатки SPA приложений......................... 6 1.3 Требования для качественной разработки SPA-приложения.................. 10 1.4 Технологии одностраничных web-приложений, используемых на стороне клиента. ................................................................................................. 12 1.5 Технологии одностраничных web-приложений, используемых на стороне web-сервера. ......................................................................................... 19 1.6 Системы управления базой данных наиболее используемые в одностраничных web-приложениях. ................................................................ 23 ГЛАВА 2. МИКРОСЕРВИСНАЯ АРХИТЕКТУРА. ......................................... 33 2.1 Знакомство с микросервисной архитектурой. .......................................... 33 2.2 Монолитная архитектура и ее недостатки ................................................ 34 2.3 Преимущества микросервисов. .................................................................. 36 ГЛАВА 3. РАЗРАБОТКА ОДНОСТРАНИЧНОГО WEB-ПРИЛОЖЕНИЯ. .. 40 3.1 Описание web-приложения. ........................................................................ 40 3.2.1 Технологии, используемые в клиентской части web-приложения. .. 40 3.2.2 Технологии, используемые на серверной части web-приложения. .. 43 3.2.3 СУБД используемая в одностраничном web-приложении. ............... 45 3.2.4 Контейнеризация в web-приложении. ................................................. 48 3.2.5 Дополнительные инструменты, используемые в проекте ................. 49 3.3 Разработка одностраничного web-приложения. ....................................... 49 3.3.1 Клиентская часть web-приложения. .................................................... 49 3.3.2 Серверная часть web-приложения. ...................................................... 66 3.3.3 База данных web-приложения. ............................................................. 73 ЗАКЛЮЧЕНИЕ ..................................................................................................... 75 СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ ............................................. 77 2 ВВЕДЕНИЕ Web-приложения на данный момент как никогда актуальны и невольно заменяют старые нативные приложения. Они более удобны в использовании, их легко обновлять, и они не привязаны к одному устройству. И хотя пользователи постепенно переходят от браузерных webприложений к мобильным, спрос на сложные и усовершенствованные приложения уже огромен и продолжает расти. Одним из шаблонов проектирования web-приложений является одностраничное web-приложение (SPA), которое удобно тем, что не перезагружается во время использования. Благодаря такому подходу одностраничные web-приложения избегают прерывания, вызванного отображением страниц на сервере. Это устраняет самую большую проблему, с которой обычно сталкивается мир webразработки в отношении обеспечения беспрепятственного взаимодействия с пользователем. Но одностраничные web-приложения не являются универсальным решением для всех потребностей web-разработчика. С наличием множества преимуществ, таких как, скорость, удобство, универсальность и т.д. данного подхода приходят и недостатки, которые мешают в дальнейшей разработке продукта. Например, очень страдает SEO-оптимизация, из-за отсутствия наличия всего контента в приложении; также при расширении функционала web-приложения скорее всего будут возникать сложности с выбранными технологиями, что может привести к переписыванию всего проекта; слишком долгая загрузка начальной страницы при первом переходе в web-приложение может отпугнуть потенциальных посетителей. Поэтому всегда стоит учитывать перед разработкой те моменты, которые потенциально важны в конечном продукте. Объектом исследования является одностраничное web-приложение. Предметом исследования является изучение актуальных технологий, предназначенных для разработки современных SPA-приложений. 3 Целью выпускной квалификационной работы является исследование технологий разработки SPA и создание одностраничного web-приложения. Для достижения поставленной цели необходимо решить следующие задачи: 1. Проанализировать различные интернет-источники, а также российскую и зарубежную литературу, с целью исследования современных технологий разработки SPA. 2. Изучить необходимые технологии для дальнейшей разработки приложений. 3. Разработать одностраничное web-приложение в соответствии с изученными интернет-технологиями. 4 ГЛАВА 1. ОСНОВНЫЕ ПОЛОЖЕНИЯ SPA. 1.1 История возникновения одностраничных web приложений. Изначально, когда web только зарождался, не было языка JavaScript. Первоначально были просто статические HTML-страницы, созданные для обмена документами между учеными. Как только этот формат документов и интернет стали более популярными, люди поняли, что эти документы нуждаются в усовершенствованных методах стилизации для улучшения коммуникации. И таким образом был создан язык таблиц стилей (CSS). Именно он стал стандартом для стилизации и верстки HTML-документов. Затем, компания Netscape Communications решила, что веб нуждается в языке сценариев, чтобы делать содержимое страницы более динамичным. Так появился JavaScript. Несмотря на эти особенности, первоначальная сеть все еще была очень статичной по своей природе. Когда пользователь вводит URL-адрес в свой браузер, он получает один документ - то есть фактически файл с сервера, и это будет иметь место для всевозможных введенных URLадресов. Благодаря появлению CSS и JavaScript web-сайты стали выглядеть лучше и динамичнее, но это не изменило ориентированную на страницы модель веба. По мере того как web-сайты становились все более сложными, многие web-разработчики хотели лучше контролировать свои web- документы. Они хотели динамически управлять макетом и содержанием webстраниц. Это привело к созданию Общего интерфейса шлюза (CGI). CGI был одной из первых попыток сделать серверный рендеринг (SSR). Это означает, что web-сервер, с полученным от web-браузера запросом вместо того, чтобы возвращать статические HTML-страницы, должен будет запускать процессор, который динамически генерирует страницу на основе параметров и логики, а затем отправляет ее обратно. Независимо от того, использовал ли web-сайт статическую HTML-страницу, которая не изменялась или отображала свои страницы на сервере с использованием серверной логики, в прошлом акцент делался на отправке браузерам полных HTML-страниц в виде файлов. Именно так работали сайты в целом. Эта однофайловая или 5 страничная модель совсем не похожа на то, как работают нативные приложения на персональных компьютерах или мобильных устройствах. Модель собственного приложения отличается тем, что все приложение загружается и устанавливается на устройство пользователя. Когда пользователь открывает приложение, оно готово к использованию в данный момент. Любые элементы управления, которые должны быть нарисованы на экране, генерируются из уже существующего кода, и никаких дополнительных вызовов на внутренний сервер не требуется кроме вызовов для отправки или получения данных. Это делает приложения более отзывчивыми и быстрыми, чем классические web-приложения, которые постоянно требовали обновления страницы, чтобы показать новый контент в старой модели. Стимул одностраничных web-приложений состоял в том, чтобы сделать web-приложения гораздо более похожими на собственные приложения устройств, чтобы дать им такое же ощущение скорости и отзывчивости. Следовательно, стиль SPA использует различные методы и библиотеки, чтобы заставить web-приложения функционировать и чувствовать себя более похожими на собственные приложения. 1.2 Основные преимущества и недостатки SPA приложений. Как было сказано ранее, толчком к использованию создания приложений в стиле SPA является то, что web-приложение больше похоже на нативное приложение. Используя методы приложения SPA, можно заставить нашу программу реагировать и выглядеть так, как будто она была установлена на устройстве. Web-приложения в классическом стиле могут показаться вялыми, поскольку любые изменения на странице требуют обратного ответа сервера, чтобы получить новый экран. Однако приложения в стиле SPA перерисовывают части экрана мгновенно, не дожидаясь, пока с сервера вернется новый файл. Поэтому, как пользователь, можно сказать, что приложение SPA - это нативное приложение для устройства. 6 Создание приложений SPA довольно сложное, состоящее порой из множества компонентов и библиотек, которые нужно использовать. Однако независимо от того, используется Angular, Vue, React или какой-либо другой фреймворк, есть определенные функции и требования, которые всегда будут общими для одностраничных web-приложений. Разберемся с некоторыми из них: • Как следует из названия, всё приложение находится только на одной HTML-странице. В отличие от стандартных HTML-приложений, которые используют отдельные страницы для отображения разных экранов, в SPA первая страница – это единственная страница, которая когда-либо загружалась в приложении. • Вместо статических HTML файлов, JavaScript отображает экран динамически. Следовательно, первая загруженная HTML-страница фактически почти полностью пуста. Но у этой страницы будет корневой элемент внутри тега <body/>, который станет контейнером для всего приложения, который отображается в реальном времени, при взаимодействии пользователя с приложением. «Это дает достижение минимально возможного времени загрузки страниц, просматриваемых в произвольном порядке.»[5] • Все скрипты и файлы, необходимые для запуска приложения, обычно загружаются в начале, при получении основного файла HTML. Однако этот метод перестает работать в SPA и загружается только файл сценария базового уровня, а затем идёт загрузка других скриптов по запросу к базе данных или серверу. Благодаря этому можно улучшить взаимодействие с пользователем за счет сокращения времени ожидания загрузки экрана. • Маршрутизация URL-адресов для SPA выполняется по-другому, нежели в обычных web-приложениях. В приложениях SPA есть механизм использующийся, в зависимости от выбранной вами структуры, для создания виртуальной маршрутизация. При виртуальной маршрутизация кажется, что 7 пользователь выполняет разные вызовы к разным URL-адресам на стороне сервера, однако вся «маршрутизация» происходит только в клиентском браузере, чтобы сделать логичным переходы на разные экраны. Другими словами, никаких обращений к серверу не производится и маршрутизация URL-адресов становится средством логического разделения приложения на разные экраны. Например, когда пользователь вводит URL-адрес в своем браузере и нажимает кнопку «Enter», ему возвращается с сервера страница с полным фактическим адресом, что он написал в адресной строке. Однако в случае маршрутизации в приложении SPA фактической адресации к серверу указанным URL-адресом как такового не существует. Вместо этого приложение использует URL-адрес как своего рода контейнер для разделов. приложения, а также для запуска определенного поведения. При этом маршрутизация URL-адресов по-прежнему является полезной функцией, поскольку маршрутизация – это ожидаемые результаты для большинства пользователей. Из этого вытекают следующие преимущества одностраничных webприложений: • Улучшенный UX дизайн. Понятный интерфейс для пользователя очень важен, ведь благодаря ему можно быстрее найти нужную информацию и получить нужный результат. Благодаря тому, что все необходимые данные лежат в клиентской части взаимодействия пользователя с приложением осуществляются очень легко и также легко могут отображаться на экране. SPA практически не нагружают сеть в отличие от обычных web-приложений, поскольку возвращается с сервера не полная HTML-страница, а лишь некоторые компоненты. • Скорость. Так как данные загружаются постепенно, то на взаимодействие с сервером уходит меньше усилий, а это влечёт за собой значительное увеличение скорости работы. 8 • Удобство. Благодаря снижению нагрузки на сервер в SPA-приложении увеличивается быстродействие работы приложений во всех известных браузерах и повышается удобство использования. • Автономность. Поскольку приложение передает только актуальные данные, которые запрашивает пользователь, то можно с легкостью работать с теми данными, которые были загружены заранее, даже без подключения к интернету. • Универсальность. Так как одностраничное web-приложение загружает данные по частям, задержки с сервером сведены к минимуму. Это очень помогает webприложениям с интенсивными вычислениями и трудным взаимодействием с пользователем. • Кроссплатформенность. SPA - лучший пример кроссплатформенного подхода, так как оно включает в себя адаптивный дизайн и отличную работоспособность в любом браузере. Так, обычные пользователи наслаждаются прекрасным сайтом, который отображается и на ПК, и на смартфонах одинаково хорошо, а разработчики имеют понятную структура кода. «Благодаря указанным преимуществам написанные на JavaScript SPA становятся все популярнее, а следовательно, растет спрос на опытных разработчиков и архитекторов, уверенно владеющих JavaScript.»[1] Но также есть и ряд недостатков, которые могут препятствовать процессу разработки и дальнейшей оптимизации проекта: • SEO-оптимизация. SEO (Search Engine Optimization) скорее всего станет проблемой при использовании SPA приложения. Так как весь контент размещен на одной странице, наполнить web-сайт большим количеством ключевых слов не получится. Отсутствие уникальных ссылок также повлияет на работу SEO 9 специалиста, потому что будет затруднена работа маркетинговой оптимизации сайта. • Загрузка начальной страницы. Как говорилось ранее, время загрузки отдельных состояний полезная вещь не только для разработчиков, но и для пользователей. Однако загрузка начальной страницы может огорчить потенциального посетителя сайта, так как при первом посещении она, мягко говоря, медленная. Особенно это заметно на сайтах с большим количеством данных и разнообразием контента. • XSS-атаки. XSS-атаки (или «межсайтовый скриптинг») – это атака путем внедрения кода на стороне клиента. Благодаря этому любой недоброжелатель может внедрять свои скрипты со стороны пользователя или через уязвимости в web-сервере для получения прав расширенного пользования или авторизационных данных пользователя. Также межсайтовый скриптинг может быть использован для проведения DoS-атак. 1.3 Требования для качественной разработки SPA-приложения. JavaScript и его фреймворки. Фундаментом для SPA-приложений служит JavaScript. При создании одностраничных web-приложений без него не обойтись, ведь благодаря нему происходят взаимодействия с пользователем и события. При разработке его можно применять как нативный JavaScript или же выбрать один и из его наиболее популярных фреймворков, таких как Vue, React и Angular. Конечно, каждый фреймворк по сути своей уникальный, и может выполнять те или иные задачи по своему. Поэтому прежде чем приступать к работе, нужно выбрать фреймворк, который наиболее всего подходит к поставленной задаче. AJAX. 10 Необходимой составляющей для любого SPA-приложения является AJAX. Именно он ответственен за переходы в web-приложении без перезагрузки страницы, а также обеспечивает обмен данными между пользователем и web-сервером. Обычно он встроен в фреймворки JavaScript, но при использовании нативного JavaScript без него не обойтись. Back-end технологии. При разработке SPA-приложения очень важен выбор серверной составляющей. Кому-то будет достаточно Python фреймворка Django, потому что он обладает замечательной встроенной панелью администрирования, но при большом количестве одновременных посещений производительность оставляет желать лучшего. Для кого-то идеальным вариантом будет Node.js, а кому-то подойдет PHP с его фреймворками. Здесь главное понимать, на что способен тот или иной фреймворк и что требуется от него вам для разработки. Так, например можно использовать Django framework для backend разработки, а для front-end взять Vue, и этого будет достаточно для создания какого-нибудь информационного web-приложения с различной тематикой. Система управления базами данных. Что касается баз данных, то тут тоже придется принимать решение какую выбрать, ведь их вариации множество. Для начала придется определиться, какое направление выбрать: реляционные или нереляционные базы данных. Основные различия в них заключаются в том, как они спроектированы, какие типы данных поддерживают и как их записывают. Например, среди нереляционных баз данных можно отметить MongoDB, которая хорошо справляется со сбором и обработкой больших статистических данных, но если необходимы связанность данных или наличие простых транзакций, то лучше выбрать реляционную базу данных. Например, MySQL или PostgreSQL отлично подойдет для управления структурными данными. Конечно же, стоит еще учитывать опыт работы разработчика с конкретной СУБД. 11 Команда. В идеале для разработки качественного SPA-приложения требуется целая команда специалистов, разбирающихся в соответствующих технологиях. Какие же специалисты нужны в команде? • UI/UX дизайнеры, которые смогут нарисовать удобный и привлекательный макет для будущего SPA-приложения для создания привлекательного и удобного интерфейса. • Frontend-разработчики, которые по макету дизайнеров смогут сверстать и запрограммировать все события, связанные с состояниями данных. • Backend-разработчики, описывающие внутреннюю логику webприложения для обеспечения передачи данных между клиентской частью и сервером. • QA-специалисты, которые смогут тщательно протестировать одностраничное web-приложение и устранить все баги. • Project Manager, который будет координировать работу всей команды и контролировать каждый проделанный участок работы. Time management. Time management – это абсолютный инструмент для достижения успеха всего проекта. Главным решением в этом вопросе можно назвать правильное составление списка задач и распределение его среди команды. Если дать сложную задачу неопытному разработчику, он может повиснуть над ней на долгое время, так и не решив. Нужно грамотно понимать возможности каждого члена команды и давать посильную им работу для оптимизации времени. 1.4 Технологии одностраничных web-приложений, используемых на стороне клиента. Vue.js 12 Vue.js или просто Vue – это прогрессивный JavaScript-фреймворк, использующийся для создания пользовательских интерфейсов. В 2013 году сотрудник компании Google, Эван Ю (Evan You) начал разработку над фреймворком Vue.js. Эван долгое время работал, используя фреймворк Angular и поэтому он захотел создать что-то легкое и понятное в использовании, взяв некоторые возможности из Angular. Релиз Vue состоялся в феврале 2014 года. Что же такое Vue.js? Название фреймворка созвучно с view, то есть с представлением (если говорить о модели MVC). «Vue.js - это фреймворк, позволяющий внедрять интерактивное поведение и дополнительные возможности в любой контекст, в котором выполняется JavaScript.»[4] Иначе говоря, Vue.js - это инструмент, который можно внедрять постепенно. Эту возможность можно связать с тем, что Vue.js стремится к прогрессивности. Vue можно добавить в проект в любой момент, что значительно расширит возможности web-приложения. И это отличает его от других фреймворков. Простота интеграции - это одно из его основных достоинств, особенно в сочетании с возможностью интеграции с Backend фреймворками. Также у этого фреймворка довольно обширная документация, дружелюбное сообщество и высокая производительность, что значительно упрощает его освоение. Основной концепцией Vue.js является концепция компонентов, то есть небольших частей интерфейса пользователя, которые можно использовать повторно. Благодаря этому web-приложение складывается из частей компонентов. Один компонент может включать несколько других компонентов, то есть используется древовидная иерархия. Vue.js – это реактивный фреймворк, поэтому представление (view) автоматически изменяется при изменении переменной (модели). Сравнение с другими фреймворками. Vue очень похож на React, так как они оба используют Virtual DOM и древовидную иерархию. Также они 13 оба обладают высокой производительностью и предоставляют хорошие решения для создания крупных проектов. Их отличия в основном заключается в том, что React имеет более обширную и фрагментированную экосистему, а Vue поддерживает все дополнительные библиотеки в актуальном соответствии с ядром библиотеки. Angular значительно повлиял на Vue, но так как он придерживается строгой структуры приложения, то он кажется более сложным и непонятным по сравнению с Vue, который является более гибким и модульным решением, а также более прост в изучении. Если сравнивать производительность этих двух фреймворков, то Vue производительнее и более прост в оптимизации. По словам Эвана Ю, Vue предпочитают те, кто привык к более классической модели разработки. Angular пользуется популярность у тех, кто программирует, используя методологию ООП. А React в основном используют те, кто любит функциональный стиль программирования. React.js «React — это JavaScript-библиотека для создания пользовательских интерфейсов на разных платформах»[3]. Его часто называют фреймворком, что является ошибкой. Фреймворк — это совокупность библиотек, которая находится внутри кода и вызывает его, в отличии от библиотеки, которая вызывается кодом. В общем случае одного React на деле выполняет только одну задачу, а именно показывает на странице компонент интерфейса, синхронизируя его с данными приложения, и только этой библиотеки в общем случае недостаточно для того, чтобы полностью реализовать проект. Особенности React React — не универсален, поэтому он подойдет не для любого проекта. И чтобы понять сможет ли он решить ту или иную задачу необходимо знать его плюсы и минусы. Плюсы использования React: ● С его помощью можно построить интерфейс из отдельно взятых компонентов, которые легко поддерживать. 14 ● React работает с виртуальным DOM деревом, что хорошо влияет на его производительность. ● У React имеется обширная документация, которая позволяет легче изучить данную библиотеку. ● Имеется большой список уже готовых React компонентов, который можно использовать в web-приложениях. ● В сообществе React сформировались определенные подходы по организации проекта, поэтому разработчикам можно просто использовать уже готовые и состоявшиеся договоренности. ● React — это проект с открытым исходным кодом, Поэтому его можно безопасно использовать даже в коммерческих проектах. Однако при использовании React есть особенности, которые важно учитывать: ● React занимает немалое количество памяти в приложении. Из-за этому пользователи будут дольше загружать приложение. ● Возникают проблемы с виртуальным DOM. При использовании большого количества элементов на странице будет увеличиваться и расход памяти, что отрицательно скажется на производительности. Поэтому, при разработке приложения, важно уделить время на оптимизацию таких моментов. ● Средний порог входа в React. Так как он является библиотекой, то помимо самого React придется еще использовать сторонние библиотеки, необходимые для полноценной работы. Об этих минусах стоит помнить при выборе Frontend составляющей будущего web-приложения. React является не лучшим вариантом в плане реализации проекта, в котором имеются части чувствительные к потребляемым ресурсам. В таком случае лучше использовать его гибридно, то есть web-приложение будет написано на React, а требовательные к производительности части никак не будут с ним взаимодействовать. 15 AngularJS История AngularJS началась в 2009 году, когда Miško Hevery и Adam Abrons (ныне технический директор Grand Rounds) работали над второстепенным проектом, инструментом сквозной web-разработки, который предложил онлайн-хранилище JSON, а также клиентскую библиотеку для создания web-приложения в зависимости от этого. Для публикации своего проекта они взяли имя хоста GetAngular.com. В то время Хевери уже работал в Google вместе с двумя другими разработчиками над проектом Google Feedback. Вместе они написали более 17000 строк кода за 6 месяцев, постепенно погружаясь в разочаровывающий сценарий раздувания кода и проблем с тестированием. Учитывая ситуацию, Хевери попросил своего менеджера переписать приложение с помощью GetAngular, поспорив, что он сможет сделать это в одиночку в течение 2 недель. Его менеджер согласился, и вскоре после этого Хевери проиграл ставку, так как все это заняло у него 3 недели вместо 2, однако в новом приложении было всего 1500 строк кода вместо 17000. Этого было более чем достаточно, чтобы заинтересовать Google новым фреймворком. Таким образом, тогда еще никому неизвестный фреймворк внезапно стал популярным и вскоре после этого получил название AngularJS. Первая стабильная версия AngularJS (версия 0.9.0, также известная как дыхание дракона) была выпущена на GitHub в октябре 2010 года по лицензии MIT. Когда в июне 2012 года вышел AngularJS 1.0.0 (также известный как временное господство), фреймворк уже достиг огромной популярности в сообществах web-разработчиков по всему миру. Причины такого невероятного успеха заключались в следующем: Внедрение зависимостей. AngularJS был первым фреймворком на стороне клиента, который его реализовал. Это, несомненно, было огромным преимуществом перед конкурентами, включая библиотеки, управляющие DOM, такие как jQuery. С помощью AngularJS разработчики могли писать слабо связанные и легко тестируемые компоненты, оставляя фреймворку 16 задачу их создания, разрешения их зависимостей и передачи их другим компонентам по запросу. Директивы. Их можно описать как маркеры на определенных элементах DOM, таких как элементы, атрибуты, стили и т.д. Мощная функция, которую можно использовать для определения настраиваемых и повторно используемых HTML-подобных элементов и атрибутов, которые определяют привязки данных и другие особенности поведения компонентов. Двусторонняя привязка данных. Автоматическая синхронизация данных между компонентами модели и представления. Когда данные в модели изменяются, представление отражает это изменение. Когда данные в представлении изменяются, модель также обновляется. Это происходит немедленно и автоматически, что гарантирует постоянное обновление модели и вида. Одностраничный подход. AngularJS был первым фреймворком, полностью избавившим от необходимости перезагружать страницы. Это обеспечило большие преимущества как на стороне сервера (меньшее количество сетевых запросов), так и на уровне клиента (более плавные переходы, более быстрое реагирование), и проложило путь для шаблона одностраничного web-приложения, который также будет принят в React, Vue.js и других фреймворках, созданных позже. Кеширование. Вся магия AngularJS должна была происходить на стороне клиента, без каких-либо усилий на стороне сервера, для генерации частей UI/UX. Именно по этой причине все web-приложения AngularJS можно кэшировать где угодно и сделать доступными через CDN. Можно выделить некоторые достоинства использования Angular: ● Двусторонняя привязка данных. AngularJS был построен с архитектурой Model-View-Controller. И фреймворк синхронизировал модель и представление. По мере изменения данных в модели меняется и представление. Двусторонняя привязка данных позволила разработчикам сократить время разработки, поскольку 17 не требовала написания дополнительного кода для обеспечения непрерывной синхронизации представления и модели. ● Директивы. Директивы позволяли разработчикам назначать особое поведение объектной модели документа (DOM), позволяя инженерам создавать динамический и богатый контент с помощью HTML. ● Инъекция зависимостей. Зависимости определяют, как различные части кода взаимодействуют друг с другом и как изменения в одном компоненте влияют на другие. Обычно зависимости определяются непосредственно в самих компонентах. Таким образом, каждое изменение зависимости также требует изменения компонентов. В AngularJS можно использовать инжекторы, которые определяют зависимости как внешние элементы, отделяющие компоненты от их зависимостей. Внедрение зависимостей сделало компоненты более многоразовыми, простыми в управлении и тестировании. ● популярен Сообщество. С самого начала AngularJS стал чрезвычайно среди программистов. Сильное сообщество предоставило достаточно учебных материалов, дискуссий и сторонних инструментов, чтобы начать использовать AngularJS, а также найти решение почти каждой возникающей проблемы. Также можно выделить и недостатки AngularJS: ● работают Производительность. Динамические так хорошо. Сложные приложения SPA-приложения не всегда могут быть медлительными и неудобными в использовании из-за своих размеров. ● Крутая кривая обучения. Поскольку AngularJS является универсальным инструментом, всегда существует более одного способа выполнить любую задачу. Это вызывает некоторую путаницу среди программистов. Однако обилие учебных пособий и дискуссионных вопросов позволило решить большую часть проблем. Таким образом Angular заимствует некоторые лучшие аспекты разработки на стороне сервера и 18 использует их для расширения возможностей разметки HTML в браузере. «Таким образом закладывается основа, которая упрощает и облегчает создание приложений с расширенной функциональностью.»[2] 1.5 Технологии одностраничных web-приложений, используемых на стороне web-сервера. Laravel Laravel был разработан и создан Тейлором Отуэллом как попытка дать отличную замену более старому PHP-фреймворку под названием CodeIgniter. И это было потому, что CodeIgniter не предлагал таких замечательных функций, как поддержка встроенной аутентификации клиентов и правильная авторизация пользователей. В июне 2011 года Laravel выпустила свою первую бета-версию, а позже в том же месяце был выпущен Laravel 1. Помимо аутентификации, Laravel также имеет встроенную поддержку локализации, представлений, работы с сеансами, маршрутизации запроса к конкретному контроллеру и других удивительных функций. Laravel является одним из самых популярных PHP-фреймворков, используемых по всему миру для создания web-приложений. Laravel - это выбор профессиональных разработчиков из-за его производительности, множества удобных функций и масштабируемости. Данный фреймворк придерживается структуры MVC (Model View Controller), которая позволяет легко изучать и быстро прототипировать web- приложения. Также для более удобной разработки web-приложений Laravel предоставляет встроенные функции, такие как аутентификация, почта, маршрутизация, сеансы, и многое другое. Laravel настолько прост в настройке, что вы можете создать свою собственную структуру проекта, которая соответствует требованиям вашего web-приложения. С помощью красивого и элегантного синтаксиса Laravel вы можете написать код, который является понятным и выразительным. В качестве преимуществ Laravel можно перечислить следующие: большая экосистема, которая включает в себя такие функции, как 19 мгновенное развертывание, маршрутизация модульность; и маршрутизация, шаблонизирование; аутентификация; ORM, управление маршрутизация; запрос к БД, зависимостями; контроллеры Restful; локализация. Node.js Node.js - это скомпилированный JavaScript, который работает на сервере. Node.js идеально подходит для обслуживания клиентских запросов, выполняемых через API, поэтому он особенно хорошо работает с одностраничными web-приложениями (SPA), работающими на клиенте. Node.js идеально подходит для растущего числа архитектур микросервисов в Интернете, благодаря которым клиент может получить доступ к нескольким сервисам одновременно, работающим на многих разных серверах. С функциями обратного вызова операции, такие как доступ к диску сервера, выполняются асинхронно, что позволяет Node.js обрабатывать огромное количество вызовов API одновременно с очередью запросов. Node.js никогда не ждет (блокирует), пока не получит то, что необходимо для обслуживания запроса. Он просто переходит к следующему запросу и “возвращается”, когда исходный запрос готов к обслуживанию, потому что данные, например, возвращаются с диска. Node.js никогда не блокируется, но если сотни запросов продолжают накапливаться, то эта однопоточная архитектура (один основной цикл событий) увязает, что приводит к той же медлительности, что и синхронный подход, поддерживаемый большинством скомпилированных многопоточных языков, таких как C++ и Java. Действительно, эта проблема, по-видимому, является Ахиллесовой пятой всей системы, которая фактически привела многих программистов к более новым языкам, таким как Go от Google, которые могут дать вам аналогичные возможности и производительность в среде с возможно лучшими функциями, чем JavaScript, как это происходит сегодня. 20 Node.js особенно хорошо работает с базами данных NoSQL, такими как MongoDB. С MongoDB можно получить не только высокую производительность базы данных, где не используются длинные и сложные SQL-команды, но и также драйвер MongoDB сможет работать непосредственно со структурами данных в базе данных. Node. Еще одна важная характеристика Node.js заключается в том, что один и тот же код можно запускать где угодно, с минимальными изменениями. Эта изоморфная или универсальная способность Node.js, которая в настоящее время остается в значительной степени непопулярным, но это меняется. Например, можно использовать одну и ту же объектную реализацию как в серверном, так и в клиентском коде без необходимости изменять или переписывать ее для каждой платформы. Код выполняется с самого начала запуска программы, независимо от того, компилируется он или интерпретируется. Это контрастирует с Java, которая требует, чтобы уровень компилятора выполнял один и тот же код на разных платформах. И основным достоинство Node.js является его пакетный менеджер npm (Node Package Manager) и открытые репозитории github. Благодаря этому можно получить доступ буквально к сотням тысяч Node.js модулей из npm, избавляющих от необходимости писать код JavaScript с нуля для выполнения многих, если не всех требований приложения. Добавьте к этому тот факт, что текущая работа над этими модулями в основном происходит в открытых проектах github. Node.js быстра, портативна, масштабируема, открыта и внедряется с беспрецедентной скоростью. Django Django отметил начало своего пути в 2005 году и, бесспорно, стал одним из лучших фреймворков, которые помогали разработчикам делать простые вещи всего за несколько минут. Изначально обозначив свое путешествие как фреймворк для языка Python, с его правильными функциональными возможностями, Django очень хорошо уменьшил сложности web-приложения, придав ему более упрощенный подход. 21 В отношении Django выдвигаются следующие утверждения: очень быстрый, полностью загруженный, обнадеживающе безопасный, чрезвычайно масштабируемый и невероятно универсальный. Установка Django по умолчанию может быть расширена с помощью сторонних пакетов. Хотя Django предназначен в первую очередь для fullstack webприложений (часто управляемых базами данных), он может использоваться и для предоставления backend-сервисов для мобильных приложений с помощью вызовов REST API, для создания приложений реального времени или даже системы управления контентом. Теперь перейдем к преимуществам Django, который не только действует как быстрое решение для web-разработки, но и его способность поставлять высококачественный код и прозрачное его написание обеспечивает легкодоступную платформу для клиентов с бизнеса и для разработчиков. ● Скорость. Django был разработан таким образом, чтобы помочь разработчикам сделать приложение как можно быстрее. От идеи, производства до выпуска, Django помогает сделать его экономичным и эффективным. Таким образом, он становится идеальным решением для разработчиков, имеющих основной акцент на сроки. ● Загруженность. Он работает таким образом, что включает в себя десятки дополнительных функций, чтобы помочь с аутентификацией пользователей, картами сайтов, администрированием контента, RSS- каналами и многими другими подобными вещами. Эти аспекты помогают полностью реализовать процесс web-разработки. ● Безопасность. Когда разработчики делают проект в Django, это гарантирует, что они не совершают никаких ошибок, связанных с безопасностью. Некоторые из распространенных ошибок включают SQLинъекцию, подделку межсайтовых запросов, кликджекинг и межсайтовые сценарии. Для эффективного управления именами пользователей и паролями ключом является система аутентификации пользователей. 22 ● Масштабируемость. Самые загруженные сайты используют эту среду для быстрого удовлетворения потребностей в трафике. ● Универсальность. Управление контентом, научные вычислительные платформы и даже крупные организации - все эти аспекты очень эффективно управляются с помощью Django. Вместе с достоинствами приходят и недостатки. Есть много недостатков Django, упомянутых ниже. ● Django слишком монолитен. ● Все основано на Django ORM. ● Все компоненты развертываются одновременно. ● Для работы требуется знание полной системы. Хотя есть много плюсов и минусов Django, однако, когда рассматривается проект с маленьким сроком сдачи, использование Django обеспечивает быстрое решение для проекта. И чтобы ускорить его еще больше, необходимо установить пользовательскую конфигурацию модели пользователя. Раньше при разработке кода требовалось много времени, но с помощью Django это стало намного проще. Затраты на разработку сокращаются почти до 80%, а аутсорсинг полностью разрушается. 1.6 Системы управления базой данных наиболее используемые в одностраничных web-приложениях. MySQL MySQL - это система управления реляционными базами данных с открытым исходным кодом (СУБД), которая первоначально была разработана компанией MySQL AB в 1995 году. Позже эта система была приобретена корпорацией Oracle. Это программное обеспечение с открытым исходным кодом, которое можно использовать бесплатно, и их код обычно делается открытым, чтобы другие разработчики могли его модифицировать. Как упоминалось ранее, MySQL - это одна из популярных систем СУБД, которая в основном используется в Интернете вместо автономного управления данными. MySQL написан на языках C и C++ и 23 поддерживает все основные платформы, такие как Windows, Linux, Solaris, macOS и FreeBSD. Поскольку сервис бесплатный и с открытым исходным кодом, он довольно популярен среди стартап-проектов. Можно выделить следующие преимущества СУБД MySQL: ● Производительность. Производительность жизненно важна для любой системы управления базами данных, поэтому после стольких лет разработки можно спокойно доверять производительности MySQL. Основная особенность MySQL заключается в том, чтобы заставить его быстро получать данные, а также быстро получать их, даже если он жертвует некоторыми другими важными функциями, что положительно влияет на производительности. MySQL обычно имеет лучшую производительность при выполнении простых запросов, которые используются каждый день, таких как поиск первичных ключей, запросы диапазона и т.д. Новейший механизм хранения данных InnoDB, теперь используемый по умолчанию для новых таблиц, был перепроектирован, чтобы использовать преимущества многоядерных систем. ● Переносимость. MySQL - это кросс-платформенный сервер баз данных. Он может работать на различных платформах, таких как Linux, Solaris, Windows и т.д. Это хороший выбор для тех проектов, которые ориентированы на несколько платформ, особенно для web-приложений. На самом деле MySQL является частью знаменитого серверного стека LAMP (Linux Apache MySQL PHP), который используется во всем мире для разработки web- приложений. MySQL поддерживает множество платформ с различными языками, такими как C, C++, PHP, PERL, JAVA, Python и т.д. ● Бесшовное соединение. Существуют различные безопасные и бесшовные механизмы соединения, доступные для соединения с сервером MySQL. Эти соединения включают именованные каналы, сокеты TCP/IP и сокеты UNIX. ● Быстрое развитие и безотказная система. 24 MySQL работает круглосуточно и предлагает широкий спектр решений высокой доступности, включая специализированные кластерные сервера и конфигурации репликации master/slave. MySQL имеет очень большое сообщество разработчиков, которое выпускает регулярные обновления для MySQL. ● Безопасность данных. MySQL признана во всем мире самой безопасной и надежной системой управления базами данных, используемой в популярных webприложениях, включая WordPress, Drupal, Joomla, Facebook и Twitter. Данные защищены паролем, и хорошо, что эти пароли хранятся в зашифрованном виде и не могут сломать эти сложные алгоритмы шифрования. Недостатками MySQL являются следующие моменты: ● Хранимые процедуры ограничены. По сравнению с Postgresql, MySQL имеет несколько вариантов, когда вам нужно написать хранимую процедуру. Хранимая процедура обеспечивает повторное использование кода и инкапсуляцию. Но в MySQL не так много вариантов, как в других СУБД, таких как Postgresql. ● MySQL трудно масштабировать. MySQL не предназначен для масштабирования, даже невозможно заставить его масштабироваться, как это сделал Facebook, но для того, чтобы это стало возможным, требуются серьезные инженерные усилия, обычно нужно много усилий, чтобы заставить его работать. Трудности, связанные с масштабируемостью MySQL, заставляют людей переключаться на базы данных NoSQL, такие как MongoDB. ● MySQL не для больших данных. MySQL отлично работает в большинстве небольших или средних приложений, но когда размер данных растет, производительность снижается. При росте данных только простой и индексированный запрос получает хорошую производительность, для сложного запроса он легко замедляется. 25 MongoDB MongoDB - это мощная, хорошо масштабируемая, бесплатная база данных с открытым исходным кодом на базе NoSQL. Изначально MongoDB была выпущена 11 февраля 2009 года, и с тех пор заняла позицию ведущей базы данных NoSQL. Компания MongoDB Inc. (Нью-Йорк, США) поддерживает и управляет развитием MongoDB. Они также предоставляют коммерческую версию MongoDB, которая также включает поддержку. Исходный код MongoDB доступен на Github. За прошедшие годы MongoDB стала популярным выбором в качестве высокомасштабируемой базы данных, и в настоящее время она используется в качестве внутреннего хранилища данных многих известных организаций, таких как IBM, Twitter, Zendesk, Forbes, Facebook, Google и многих других. MongoDB также привлекла внимание сообщества разработчиков ПО с открытым исходным кодом, и многие разработчики работают над различными проектами с открытым исходным кодом, основанными на MongoDB. MongoDB - это хранилище данных на основе документов, что означает, что оно хранит информацию в неструктурированном формате по сравнению со структурированными таблицами, такими как MySQL или PostgreSQL. По сути, это означает, что данные, хранящиеся в MongoDB, не содержат схемы. Следовательно, MongoDB предоставляет быструю и масштабируемую службу хранения данных, что делает ее популярным выбором в приложениях, критичных к производительности. Более того, тот факт, что MongoDB написан на C ++, делает его еще быстрее по сравнению с множеством других баз данных. «Основной причиной отказа от реляционной модели является упрощение горизонтального масштабирования, но есть и другие преимущества»[7] MongoDB не следует использовать в приложениях, требующих объединения таблиц, просто потому, что он не поддерживает объединения (например, в SQL). Это связано с тем, что данные, хранящиеся в MongoDB, не структурированы, и поэтому выполнение объединений является очень 26 трудоемким процессом, который может привести к снижению производительности. Преимущества использования MongoDB: ● Вместо того, чтобы хранить поля в отдельных таблицах базы данных, как в SQL, MongoDB хранит их вместе, в одном «документе». Это ускоряет процесс извлечения данных. Большинство крупномасштабных приложений, таких как Facebook, требуют этого незначительного увеличения производительности из-за того, что приложение используют миллиарды пользователей, и поэтому даже незначительное увеличение производительности может иметь большое влияние в целом. Это одно из важнейших преимуществ использования MongoDB. ● Кластеризация. MongoDB позволяет сегментировать данные между узлами в кластере, чтобы гарантировать отсутствие единой точки отказа на сервере базы данных. ● Поддержка вторичных индексов. MongoDB позволяет использовать не только первичный индекс, но и вторичный индекс, который важен для многих приложений. ● Кеширование. MongoDB кэширует много данных, чтобы обеспечить более быстрое извлечение результатов запроса. ● Отличный набор функций. В MongoDB есть различные функции (специальные запросы, индексирование, репликация, балансировка нагрузки, хранилище файлов, агрегация, выполнение серверного JavaScript, ограниченные коллекции и т. д.), Которые делают его очень удобной базой данных. MongoDB - это база данных NoSQL, поэтому она не соответствует требованиям ACID (атомарность, согласованность, изоляция, надежность). Хоть она и выглядит очень удобной и производительной, но все таки ее не стоит использовать в приложениях, где требуется соответствие ACID 27 (например, приложения, требующие транзакций на уровне базы данных). Кроме того, в отличие от многих баз данных, MongoDB не поддерживает хранимые процедуры. Точная производительность базы данных MongoDB зависит от множества факторов. Например: ● Сценарий использования: некоторые приложения требуют структурирования данных. В таких ситуациях лучше использовать базы данных на базе SQL. В других приложениях структурировать данные практически невозможно. Здесь лучше всего работает MongoDB. ● Хранение: естественно, производительность (чтение и запись в секунду) будет сильно зависеть от базового механизма хранения. Например, твердотельные накопители, безусловно, быстрее, чем обычные жесткие диски, и поэтому производительность на твердотельных накопителях выше. ● ОЗУ: производительность базы данных во многом зависит от кэширования, а объем информации, которая может быть кэширована, зависит от ОЗУ, доступного для базы данных. ● Кластеризация: MongoDB можно использовать для простой настройки кластера базы данных с высокой доступностью и высокой производительностью. Обычно это сложно в базах данных на основе SQL. MongoDB блестяще неструктурированных работает данных. в приложениях, требующих различные приложения Например, MapReduce, системы больших данных, приложения социальных сетей, новостные форумы и т. д. В таких случаях сложно структурировать данные по таблицам. Даже если и можно это сделать, это не всегда желательно, потому что в запросах, требующих присоединения к базе данных, производительность базы данных сильно снижается. PostgreSQL PostgreSQL - одна из старейших, но наиболее совершенных систем управления базами данных с открытым исходным кодом. Она управляется и поддерживается активным и независимым 28 сообществом, активно предоставляющим поддержку и помощь при работе с PostgreSQL. Ее можно запускать на различных платформах, таких как Windows, Linux и Mac. Она может использоваться программистом, менеджером проекта и системным администратором или любым специалистом по программному обеспечению для создания продуктов, web-сайтов, инструментов и т. д. Она требует минимального обслуживания из-за ее стабильности. PostgreSQL позволяет определять собственные типы данных и индексов, а также разрабатывать собственные плагины в соответствии с любыми представленными ей требованиями. PostgreSQL предоставляет некоторые функции, сравнимые с Oracle и DB2, такие как полное соответствие ACID и контроль одновременного выполнения нескольких версий для обеспечения надежной невыполненной транзакции и обеспечения поддержки в случае высоких одновременных нагрузок. Она обладает высокой расширяемостью за счет поддержки типов индексов GIN и GIST, базы данных NoSQL и предоставляет различные функции для разработки приложений на основе документов или ключей. Преимущества использования PostgreSQL: ● Сделки. Можно не беспокоиться о дополнительном коде для обработки ошибок, при отсутствии транзакции, ведь есть база данных, которая предоставляет транзакции. PostgreSQL предоставляет транзакционный DDL. Это не просто INSERT, UPDATE или DELETE для транзакции, это фактически такие вещи, как создание таблицы, удаление и т. д. Это сильно отличается от того, как работает Oracle. Например, если внесены изменения в таблицу, транзакция будет немедленно зафиксирована. Это действительно важно, когда имеется сложное реляционное приложение, и приходится вносить изменения в приложение одновременно с изменениями, подчеркивающими схему базы данных. Это можно применить к изменениям приложения, оно внесет все изменения в приложение сразу в рамках одной транзакции. 29 ● Комментарии к коду. В отличие от других СУБД, PostgreSQL предоставляет комментарии к коду. Комментарии к коду помогают увидеть, что делает или чего не делает конкретный код. Это означает, что можно понять дизайн и появится возможность следить за процессом проектирования и открывать его. Это дает безопасность, качество и возможность развивать сообщество, потому что больше людей могут участвовать и видеть, что происходит в коде. Таким образом, идея комментирования кода ведет к созданию полностью функционального сообщества с открытым исходным кодом, а не просто к мертвому фрагменту кода на Github. ● Параметры. Назначение параметров – это интеллектуальная настройка, и если нужно ее изменить, то есть возможность посмотреть руководство, выяснить, что это такое, и изменить параметр. PostgreSQL имеет множество настраиваемых параметров. Во многих системах баз данных устанавливаются параметры среды, но устанавливаются они на уровне всей базы данных. Неважно, сколько параметров есть, важно иметь возможность изменить их, когда вам нужно их изменить. Например, есть много случаев, когда у самого PostgreSQL есть внутренние параметры, но настраиваются эти параметры в соответствии с измерениями того, как они используются в системе. Например, объем памяти, который нужно предоставить серверу. В результате есть часть информации, которую вычислили в базе данных. Еще одна особенность параметров заключается в том, что устанавливаются они в самых разных местах. Например, можно установить их для сеанса, даже можно установить их для транзакции и функции. ● Расширяемость. «Одной из главных отличительных особенностей системы PostgreSQL является ее расширяемость: возможность включения средств поддержки новых классов приложений, новых типов данных и т. п.»[6] Можно расширить базу данных до непредельных размеров. Так что, если нужна 30 дополнительная функция в PostgreSQL, можно добавить ее самостоятельно. С другими базами данных это довольно сложно. Расширяемость - это целый набор различных аспектов PostgreSQL. Это позволяет придумывать функции, типы данных, языки, всевозможные различные изменения, которые можно установить на свой сервер базы данных, просто сказав создать расширение, а затем он сделает все остальное. Недостатки PostgreSQL: У СУБД PostgreSQL не так много недостатков. Однако разница заключается в том, что некоторые люди выбирают базу данных NoSQL, которая представляет собой более новую технологию, а не базу данных SQL. ● Структура базы данных. База данных в Postgres обычно используется как реляционная база данных. Это означает, что у нас есть база данных, которая работает с некоторыми предположениями или определенным образом. И это, конечно же, язык SQL, который используете везде. Такая база данных работает с таблицами, такими как корзина данных или контейнер для хранения. Итак, в мире SQL, когда запрашиваются данные с помощью SQL, то будут очень строгие требования к данным, которые хранятся в таблице базы данных. С четкой схемой того, какие данные могут входить в таблицу, и эта схема определяется полями. И каждая новая запись имеет значение для этих полей. Но важно то, что в ней не может быть больше полей, чем определяется для таблицы. С другой стороны, база данных NoSQL, такая как MongoDB, хранит данные в виде документа. Документы могут иметь разные атрибуты, поэтому фиксированной схемы нет. ● Медленная производительность. Есть различные проблемы с производительностью и проблемы восстановления резервных копий, с которыми люди сталкиваются при использовании PostgreSQL. Часто у людей есть запрос, который выполняется медленно, и очевидно, что наблюдается снижение производительности. При поиске запроса PostgreSQL из-за своей структуры реляционной базы данных 31 должен начинать с первой строки, а затем читать всю таблицу, чтобы найти соответствующие данные. Поэтому он работает медленнее, особенно когда в строках и столбцах таблицы хранится большое количество данных, содержащих множество полей с дополнительной информацией для сравнения. PostgreSQL действительно полезен для разработчиков, поскольку имеет множество функций. Его функциональность не ограничивается помощью только разработчикам, но также и администраторам в защите целостности их данных и предоставлении такой среды базы данных, в которой можно легко управлять своими данными, независимо от того, насколько велик или мал набор данных. В дополнение к этому, он бесплатный и легко расширяемый, так что можно определять свои собственные типы данных или создавать собственные функции или даже писать разные коды без ущерба для базы данных. 32 ГЛАВА 2. МИКРОСЕРВИСНАЯ АРХИТЕКТУРА. 2.1 Знакомство с микросервисной архитектурой. Чтобы понять, как работает микросервисная архитектура, нужно уяснить, что вообще значит микросервис. Микросервис - это маленький и независимый программный процесс, который выполняется по собственному расписанию развертывания и может обновляться независимо от других. Благодаря этому определению можно понять, что микросервис обладает возможностью обновляться независимо от других микросервисов. Также он может принадлежать и управляться как одним разработчиком, так и командой разработчиков. Разработчик или команда также могут управлять несколькими другими микросервисами. Каждый разработчик/команда несет ответственность за микросервисы, которыми вледеет. В современном мире программирования это часто включает в себя разработку, тестирование, развертывание и операции. Отдельный микросервис может быть открыт внешнему миру, чтобы клиенты могли взаимодействовать с ним, или это может быть чисто внутренняя услуга, недоступная извне. Обычно он имеет доступ к базе данных, файловому хранилищу или какому-либо другому методу сохранения состояния. «Уникальность микросервисов обусловлена тем, что каждый из них разрабатывается, тестируется, развертывается и масштабируется независимо от других микросервисов.»[8] Сам по себе один микросервис мало что делает. Однако хорошо продуманную систему можно разложить на такие простые сервисы. Службы должны сотрудничать друг с другом, чтобы обеспечить функции и функциональность большего приложения. Такая совокупность служб называется микросервисным приложением. Микросервисное приложение традиционно известно как распределенное приложение, система, состоящая из небольших компонентов, которые живут в отдельных процессах и взаимодействуют через сеть. Каждая служба или компонент находится на логически отдельном (виртуальном) компьютере, а иногда даже на физически отдельном компьютере. 33 Микросервисное приложение - это распределенная программа, состоящая из множества небольших служб, которые сотрудничают для достижения функций и функциональности всего проекта. Как правило, микросервисное приложение имеет одну или несколько служб, которые внешне доступны для пользователей, которые могут взаимодействовать с системой. 2.2 Монолитная архитектура и ее недостатки Хотя распределенные вычисления существуют уже несколько десятилетий, приложения часто строились в монолитной форме. Именно так было разработано большинство программного обеспечения до облачной революции и микросервисов. Монолит - это целое приложение, которое выполняется в одном процессе. Гораздо проще построить монолит, чем микросервисное приложение. Для этого понадобится меньше технических и архитектурных навыков. Это отличная отправная точка при создании нового приложения, скажем, для продукта на ранней стадии, и вы хотите проверить правильность бизнес-модели, прежде чем приступать к более высоким техническим инвестициям, необходимым для приложения микросервисов. Монолит - отличный вариант для создания одноразового прототипа. Это также может быть все, что нужно для приложения с небольшой областью применения или приложения, которое быстро стабилизируется и не нуждается в развитии или росте в течение всего срока службы. Если приложение всегда будет таким маленьким, то имеет смысл, чтобы оно было монолитом. Большинство продуктов, как правило, нуждаются в росте и развитии, и по мере того, как монолит растет и имеет больше полезных функций, становится все труднее оправдать выбрасывание прототипа. Монолиты имеют множество потенциальных проблем. Они начинаются с малого, и у нас всегда есть лучшие намерения поддерживать код чистым и хорошо организованным. Команда хороших разработчиков может поддерживать 34 монолит элегантным и хорошо организованным в течение многих лет. Но с течением времени видение может быть потеряно. Весь код выполняется в одном и том же процессе, так что нет никаких препятствий и ничего, что помешало бы написать огромный “спагетти” код, который будет почти невозможно разобрать позже. Текучесть кадров также оказывает большое влияние. Когда разработчики покидают команду, они забирают с собой важные знания, и их заменяют новые разработчики, которым придется разработать свою собственную модель приложения, которая легко может противоречить первоначальному видению. Проходит время, код много раз может переходить из рук в руки, и это способствует превращению кодовой базы в нечто непонятное. Обновление кода для монолита - дело рискованное. Когда вносятся изменения в код, которые нарушают монолит, всё приложение прекращает работу, тогда и клиенты, и сама компания несет убытки. Можно захотеть изменить только одну строку кода, но все равно нужно развернуть весь монолит и разбить его. Этот риск вызывает страх развертывания. Страх замедляет темпы развития. Кроме того, по мере того, как структура монолита вырождается, возрастает риск его разрушения непредвиденными способами. Тестирование становится все сложнее и порождает еще больший страх перед развертыванием. Из-за огромного размера установленного монолита тестирование проблематично, и из-за его чрезвычайно низкого уровня детализации его трудно масштабировать. В конце концов, монолит расширяется, чтобы потреблять физические пределы машины, на которой он работает. По мере того как новый монолит потребляет все больше и больше физических ресурсов, его запуск становится все более дорогостоящим. Несмотря на возможные трудности с монолитом, он остается самым простым способом загрузить новое приложение. Многие приложения всегда будут маленькими. В дикой природе существует множество небольших монолитов, которые хорошо выполняют свою работу и не нуждаются в масштабировании или развитии. Поскольку они не расширяются, они не 35 страдают от проблем роста. Если приложение останется небольшим и простым и не нуждается в дальнейшем развитии, определенно стоит смотреть в сторону монолита. Однако есть много приложений, которые выиграют от подхода, ориентированного на микросервисы. Эти виды приложений будут постоянно развиваться в течение многих лет. Другие приложения, которые могут получить выгоду это те, которые должны быть гибкими, масштабируемыми или иметь ограничения безопасности с самого начала. Создавать эти типы приложений намного проще, если начать разработку с микросервисов, потому что преобразование существующего монолита сложно и рискованно. В любом случае, если нужно сначала проверить свою бизнес-идею, сделайте это лучше изначально построив монолит. Однако даже в этом случае с правильным инструментарием создание прототипов с помощью микросервисов не намного сложнее, чем создание прототипов с помощью монолита. 2.3 Преимущества микросервисов. Создание микросервисных приложений дает много преимуществ. Каждая служба потенциально может иметь собственный выделенный ЦП, память и другие ресурсы. Однако, как правило, физическая инфраструктура разделяется между многими сервисами, и это делает микросервисы рентабельными. Но также можно разделить их, когда это необходимо, чтобы службам с самыми тяжелыми рабочими нагрузками можно было выделить необходимые ресурсы. Можно сказать, что каждая небольшая служба масштабируется независимо, и это дает возможность детально настраивать производительность приложения. ● Микросервисная архитектура осуществляет детальный контроль, то есть позволяют создавать приложение с детальным контролем над масштабируемостью. ● Минимизируют риск развертывания, то есть микросервисы помогают минимизировать риски развертывания при максимальном темпе разработки. 36 ● Позволяет выбрать свой собственный технологический стек, то есть микросервисы позволяют выбирать правильный стек для поставленной задачи, чтобы разработчики не были ограничены одним технологическим стеком. Микросервисное приложение дает возможность повысить надежность и снизить риски развертывания. При обновлении конкретной службы, можно сделать это без риска поломки всего приложения. Конечно, все еще существует риск сломать приложение, но это лучше и легче исправить, чем отключение всего приложения. Когда возникают проблемы, легче откатить только небольшую часть системы, чем всю систему. Снижение риска развертывания оказывает отрицательное влияние на частое развертывание, а это важно для гибкости и поддержания высоких темпов разработки. В конце концов, разработчики долгое время создавали микросервисные приложения, но создание таких систем стало дешевле, а инструменты улучшились. Создавать приложения таким способом и получать от этого выгоду стало проще, чем когда-либо прежде. По мере снижения затрат и повышения удобства развертывания услуги ориентировались на микроуровень, и это принесло свои собственные преимущества. Маленькие сервисы в совокупности загружаются быстрее, чем одно большое. Это помогает сделать систему более масштабируемой, поскольку можно быстро реплицировать любую перегруженную службу. Маленькие службы также легче тестировать и устранять на них неполадки. Несмотря на то, что тестирование всей системы все еще может быть трудным, нам легче доказать, что каждая ее часть работает должным образом. Создание приложений с множеством небольших и независимо обновляемых частей означает, что можно иметь приложение, которое легче поддается расширению, развитию и изменению в течение его срока службы. Тот факт, что границы процессов между компонентами установлены, означает, что никогда не возникнет соблазна написать “спагетти-код”. Влияние плохого кода будет контролироваться и изолироваться, потому что 37 каждый микросервис должен быть достаточно маленьким, чтобы его можно было выбросить и переписать в кратчайшие сроки. вопрос недель, если не дней. В этом смысле разрабатывается код для одноразового использования. Постоянная и итеративная замена приложения не только стала возможной, но и активно поощряется, и именно это необходимо для архитектуры приложений, чтобы выдержать постоянно меняющиеся потребности современного бизнеса. Еще одно преимущество, которое действительно вдохновляет разработчиков, использующих микросервисы, заключается в том, что программисты больше не ограничены одним технологическим стеком для приложения. Каждая служба в приложении потенциально может содержать любой технический стек. Для более крупных компаний это означает, что разные команды могут выбирать свой собственный стек технологий; они могут выбрать его на основе своего опыта или на основе стека, который лучше всего подходит для выполняемой работы. Различные стеки технологий могут сосуществовать в кластере и работать вместе, используя общие протоколы и механизмы связи. Возможность переключения между техническими стеками важна для долгосрочной работоспособности приложения. По мере развития технологического ландшафта, как и всегда, старые технологические стеки теряют популярность и в конечном итоге должны быть заменены новыми. Микросервисы создают структуру, которую можно постепенно преобразовывать в новые технологические стеки. 2.4 Недостатки микросервисов В наши дни один опытный разработчик может самостоятельно запускать приложение с микросервисами без поддержки команды. Честно говоря, инструменты по-прежнему сложны. Обычно, чтобы преодолеть кривую обучения самостоятельно, требуются месяцы или больше - освоение любого из этих инструментов требует значительного времени! На самом деле перед разработчиками микросервисов стоят две проблемы. Первая проблема - это крутая кривая обучения. Чтобы научиться создавать микросервисы, необходимо изучить не только сложный набор технологий, но также 38 принципы и методы построения распределенных приложений. Во-вторых, создание приложения для микросервисов, да и любого распределенного приложения, будет сложнее, чем создание эквивалентного монолита. И ведь действительно, создание монолита вначале проще и во многих случаях это правильное решение. Однако, если приложение является одним из тех, которые позже необходимо преобразовать или реструктурировать в микросервисы, следует подумать о возможных затратах на распутывание большого и неорганизованного кода. К счастью, микросервисы предлагают реальные способы управления сложностью. Если правильно работать с микросервисами, то можно понять, что создание микросервисов, по крайней мере, в определенных ситуациях, на самом деле не так сложно, чем создание монолита. Микросервисы как архитектурный образец - один из инструментов, который помогает справляться со сложностями разработки приложений. Микросервисы предлагают реальные способы управления сложностью нашего приложения. Они обеспечивают жесткие границы, которые не позволяют писать спагетти-код. 39 ГЛАВА 3. РАЗРАБОТКА ОДНОСТРАНИЧНОГО WEBПРИЛОЖЕНИЯ. 3.1 Описание web-приложения. В качестве практической части данной работы было предложено разработать одностраничное «СмолМедПрепараты». web-приложение Целью созданию для сайта компании является ООО описание деятельности компании. К web-приложению были предъявлены следующие требования реализации: Возможность осуществления обратной связи через электронную почты. Наличие адаптивного дизайна, чтобы сайт хорошо выглядел как на персональных компьютерах, так и на мобильных устройствах. Возможность легко вставлять новости компании. Возможность выставлять информацию о производимых препаратах. Поддержка русского и английского языков. Лаконичное описание деятельности компании. Возможность просмотра лицензий и иных документов компании. Информация для связи с компанией для потенциальных инвесторов и работников. 3.2 Программные средства реализации одностраничного webприложения. 3.2.1 Технологии, используемые в клиентской части webприложения. VuetifyJS При создании приложения, соответствующего стандарту Material Design, вероятно, лучшим выбором будет Vuetify.js. Vuetify - это многоразовая структура семантических компонентов для Vue.js, цель которой - предоставить чистые, семантические и повторно используемые 40 компоненты. Он поддерживает все современные браузеры и совместим с Vue CLI-3. Он также предлагает базовые шаблоны для простого HTML, Webpack, NUXT, PWA, Electron, Apache Cordova. К сожалению, документация не очень обширная. Все многочисленные компоненты задокументированы, но в некоторых отсутствуют детали и примеры. Иногда это может расстраивать, поскольку может потребоваться больше времени, пытаясь понять, как работает определенный компонент. К счастью, это не очень распространенная проблема, но рекомендуется проверить ее, соответствует ли она вашим ожиданиям, прежде чем начинать разработку проекта. Реализация Material Design в Vuetify очень строгая, что дает преимущества в том, что касается стандартизации стилей и повторного использования компонентов. С другой стороны, он не дает слишком большой свободы для настройки стиля: изменение стиля элемента по умолчанию - дело хлопотное, но с этим следует согласиться, поскольку это не является одной из целей Vuetify. Vuetify Date Range Picker Компонент фреймворка Vuetify, предназначенный для выбора диапазона дат. Vuetify Date Range Picker бывает двух вариантов ориентации: книжная (по умолчанию) и альбомная. По умолчанию он генерируют событие ввода, когда наступает день (для выбора даты) или месяц (для выбора месяца), но с реактивной опорой он может обновлять модель даже после нажатия на год / месяц. Vuex Vuex — паттерн управления состоянием, который еще является и библиотекой для приложений на Vue.js. Он служит централизованным хранилищем данных для всех компонентов приложения с правилами, гарантирующими, что состояние может быть изменено только предсказуемым образом. Vuex помогает управлять совместно используемым состоянием ценой привнесения новых концепций и вспомогательного кода. Компромисс, когда 41 кратковременная продуктивность страдает на благо долгосрочной. Впервые столкнувшись с созданием крупных SPA, Vuex может показаться многословным и сложным. Но довольно простые приложения могут легко обходиться и без Vuex. Vue Router Vue Router — официальная библиотека маршрутизации для Vue.js. Она глубоко интегрируется с Vue.js и позволяет легко создавать SPAприложения. Включает следующие возможности: ● Вложенные маршруты/представления ● Модульная конфигурация маршрутизатора ● Доступ к параметрам маршрута, query, wildcards ● Анимация переходов представлений на основе Vue.js ● Удобный контроль навигации ● Автоматическое проставление активного CSS класса для ссылок ● Настраиваемое поведение прокрутки страницы Babel Babel — это бесплатный компилятор (транспайлер) JavaScript с открытым исходным кодом, который в основном используется для преобразования кода ECMAScript 2015+ (ES6+) в обратно совместимую версию JavaScript, которую могут запускать старые движки JavaScript. Babel — популярный инструмент для использования новейших возможностей языка программирования JavaScript. Разработчики могут использовать новые возможности языка JavaScript, используя Babel для преобразования своего исходного кода в версии JavaScript, которые могут обрабатывать web-браузеры. Плагины Babel используются для преобразования синтаксиса, который не поддерживается широко, в обратно совместимую версию. Например, стрелочные функции, указанные в ES6, преобразуются в обычные объявления функций. Нестандартный синтаксис JavaScript, такой как JSX, также можно преобразовать. Babel предоставляет 42 полифилы для поддержки функций, которые полностью отсутствуют в средах JavaScript. Например, статические методы, такие как Array.from, и встроенные, такие как Promise, доступны только в ES6+, но их можно использовать в более старых средах, если используется полифилл Babel. Webpack Webpack — это сборщик модулей. Грань между сборщиком и исполнителем задач стала размытой благодаря плагинам для web-пакетов, разработанным сообществом. Иногда эти плагины используются для выполнения задач, которые обычно выполняются вне web-пакета, таких как очистка каталога сборки или развертывание сборки. React и Hot Module Replacement (HMR) помогли популяризировать webpack и привели к его использованию в других средах, таких как Ruby on Rails. Несмотря на свое название, webpack не ограничивается только сетью. Webpack полагается на модули. Самый маленький проект, который вы можете связать с webpack, состоит из ввода и вывода. Процесс объединения начинается с пользовательских записей. Сами записи являются модулями и могут указывать на другие модули посредством импорта. При объединении, проект с помощью webpack проходит через импорт, строит граф зависимостей, а затем генерирует выходные данные на основе конфигурации. Кроме того, можно определить точки разделения для создания отдельных пакетов в самом коде проекта. Внутренне webpack управляет процессом объединения, используя так называемые блоки, и этот термин часто встречается в документации, связанной с webpack. 3.2.2 Технологии, используемые на серверной части webприложения. Django Django - это фреймворк для разработки web-приложений на языке python. Одним из преимуществ Django является огромное количество, модулей, что позволяет разработчикам ускорить разработку приложений, так 43 как нет необходимости все кодировать с нуля. Django содержит готовые решения следующих задач: ● Безопасность: Django приложение содержит модули для защиты от большинства атак, таких как SQL Injection, XSS, CSRF, Clickjacking и многих других. ● Администрирование: Django поставляется со встроенной панелью администрирования, которая упрощает и ускоряет разработку, поскольку нет необходимости создавать отдельную панель администратора. ● Создание Api: Django позволяет создать REST Api для облегчения взаимодействия с другими web-приложениями Django REST framework Django REST framework - инструментарий для создания REST webAPI в Django приложение. REST представляет собой архитектурный стиль для обеспечения стандартов между компьютерными системами в Интернете, что упрощает взаимодействие систем друг с другом. REST-совместимые системы, часто называемые системами RESTful, характеризуются тем, что они не имеют состояния и разделяют проблемы клиента и сервера. В архитектурном стиле REST реализация клиента и реализация сервера могут выполняться независимо друг от друга, не зная друг о друге. Это означает, что код на стороне клиента можно изменить в любое время, не влияя на работу сервера, а код на стороне сервера можно изменить, не влияя на работу клиента. Пока каждая сторона знает, какой формат сообщений отправлять другой, они могут быть модульными и отдельными. Так как проблемы пользовательского интерфейса отделены от проблем хранения данных, это улучшает гибкость интерфейса для разных платформ и улучшает масштабируемость. Кроме того, разделение позволяет каждому компоненту развиваться независимо. Используя интерфейс REST, разные клиенты обращаются к одним и тем же конечным точкам REST, выполняют одни и те же действия и получают одинаковые ответы. 44 Системы, которые следуют парадигме REST, не имеют состояния, что означает, что серверу не нужно ничего знать о том, в каком состоянии находится клиент, и наоборот. Таким образом, и сервер, и клиент могут понимать любое полученное сообщение, даже не просматривая предыдущие сообщения. В архитектуре REST клиенты отправляют запросы на получение или изменение ресурсов, а серверы отправляют ответы на эти запросы. Для взаимодействия клиента и сервера в REST системах используются 4 основных HTTP-команды: GET - получить определенный ресурс (по идентификатору) или коллекцию ресурсов, POST - создать новый ресурс PUT - обновить конкретный ресурс (по id), DELETE - удалить определенный ресурс по идентификатору, однако в разных системах разные HTTP команды отвечают за разные действия, например, POST может как создавать новый ресурс, так и редактировать существующий. 3.2.3 СУБД используемая в одностраничном web-приложении. PostgreSQL - Реляционная база данных с открытым исходным кодом. PostgreSQL полностью соответствует требованиям ACID и имеет прочную основу для обеспечения целостности данных и параллелизма. ACID - это аббревиатура свойств, описывающих требования к СУБД и содержит следующие свойства: атомарность, последовательность, изоляцию и долговечность. Атомарность означает, что сложная операция с базой данных обрабатывается как одна инструкция, даже если она состоит из разных операций. Согласованность означает, что данные в базе данных всегда хранятся непротиворечивый, то есть он не поврежден из-за частично выполненного операции. Изоляция позволяет базе данных обрабатывать параллелизм в "правильный путь", то есть без искажения данных из чередующихся изменения. Надежность означает, что ядро базы данных должно защитить данные, которые он содержит, даже в случае программного и аппаратного обеспечения неудач, насколько это возможно. PostgreSQL поставляется с процедурным языком PL/pgSQL, который можно использовать для писать многоразовые фрагменты кода, такие как функции и 45 процедуры, и он поддерживает ранее и после триггеров, представлений, материализованных представлений и секционированных таблиц.Экземпляр PostgreSQL называется кластером, потому что один экземпляр может обслуживать и обрабатывать несколько баз данных. Каждая база данных - это изолированное пространство, где пользователи и приложения могут хранить данные. Доступ к базе данных имеют разрешенные пользователи, но пользователи, подключенные к базе данных, не могут пересекать границ базы данных и взаимодействовать с данными, содержащимися в другой базе данных, если они не также явно подключиться к последней базе данных. База данных может быть организована в пространства имен, называемые схемами. Схема - это имя, которое пользователь может назначить для организации объектов базы данных, таких как таблицы, в более структурированные коллекции. Схемы не могут быть вложенными, поэтому они представляют собой плоское пространство имен. Объекты базы данных представлены всем, что пользователь может создавать и управлять в рамках база данных - например, таблицы, функции, триггеры и типы данных. Каждый объект принадлежит к одной и только одной схеме, которая, если не указана, является общедоступной схемой по умолчанию. Пользователи определяются на уровне кластера, что означает, что они не привязаны к конкретному база данных в кластере. Пользователь может подключаться и управлять любой базой данных в кластере, к которому у него есть доступ. PostgreSQL делит пользователей на две основные категории: Обычные пользователи: эти пользователи могут подключаться к базам данных и управлять ими в зависимости от их набора привилегий. Суперпользователи: эти пользователи могут делать что угодно с любым объектом базы данных. PostgreSQL позволяет создать столько суперпользователей, сколько нужно, и каждый суперпользователь имеет те же права: он может делать все с любой базой данных и объект и, что особенно важно, также могут управлять 46 жизненным циклом кластера (например, они могут разорвать обычные пользовательские соединения, перезагрузить конфигурацию, остановить весь кластер и т. д.). Внутренние данные PostgreSQL, такие как пользователи, базы данных, пространства имен, конфигурация и состояние выполнения базы данных, предоставляется с помощью каталогов: специальных таблиц, которые представляют информация в SQL-интерактивном виде. Многие каталоги обрезаны в зависимости от пользователя. кто их проверяет, за исключением того, что суперпользователи обычно видят весь набор доступной информация. PostgreSQL хранит пользовательские данные (например, таблицы) и свой внутренний статус в локальной файловой системе. Это важный момент, о котором следует помнить: PostgreSQL полагается на лежащие в основе файловую систему для реализации сохраняемости. В частности, PostgreSQL хранит все свои содержимое (данные пользователя и внутренний статус) в едином каталоге файловой системы, известном как PGDATA. Каталог PGDATA представляет, что кластер обслуживает как базы данных, поэтому возможно чтобы вы установили один PostgreSQL и переключились на разные каталоги PGDATA для доставки разного контента.В частности, каталог PGDATA создается как минимум журналы упреждающей записи (WAL) и хранилище данных. Без любой из этих двух частей кластер не может гарантировать согласованность данных и, в некоторых критических обстоятельствах. По сути, это возможный способ осуществлять быстрое обновление между основными версиями. Каталог PGDATA необходимо инициализировать, прежде чем он сможет использоваться PostgreSQL; в инициализация - это создание структуры каталогов внутри PGDATA Внутренне PostgreSQL отслеживает структуры таблиц, индексы, функции и все вещи, необходимые для управления кластером в выделенном хранилище, называемом каталогом. PostgreSQL каталог имеет основополагающее значение для жизненного цикла кластера и отражает 47 практически каждое действие пользователя в базе данных. PostgreSQL предоставляет пользователям доступ к каталогам базы данных с помощью интерфейса SQL, что означает, что ими можно манипулировать с помощью SQL запросов. 3.2.4 Контейнеризация в web-приложении. Docker - это централизованная платформа с открытым исходным кодом, предназначенная для создания, развертывания и запуска приложений. Вся идея Docker заключается в том, чтобы разработчики могли легко разрабатывать приложения, помещать их в контейнеры, которые затем можно развернуть где угодно. Docker использует технологию контейнеров в операционной системе хоста для запуска приложений. Это позволяет приложениям использовать то же ядро Lınux в качестве системы на главном компьютере, а не создавать целую виртуальную операционную систему. Контейнеры Docker - это легкие альтернативы виртуальной машине. Это позволяет разработчикам упаковывать приложение со всеми его библиотеками и зависимостями и размещать его как единый пакет. Преимущество использования контейнеров по сравнению с виртуальными машинами состоит в том, что вам не нужно выделять оперативную память и дисковое пространство для приложений. Контейнер автоматически создает хранилище и пространство в соответствии с требованиями приложения. Контейнеры гарантируют, что наше приложение работает в любой среде, например, при преимуществ разработке, контейнеров тестировании является или продукте. изолированность, что Одним из позволяет запускать их независимо друг от друга, при этом они могут обмениваться информацией с хостом или другими контейнерами. Контейнеры Docker основаны на образах. Образ - это шаблон, на основе которого собирается контейнер. Образ описывается в текстовым файле под названием Dockerfile. Dockerfile содержит описание необходимого 48 программного обеспечения для запуска приложения, а также настройки контейнера. 3.2.5 Дополнительные инструменты, используемые в проекте SQLAlchemy - это набор инструментов для баз данных Python с открытым исходным кодом, который обеспечивает следующие функции: ● Отображает реляционные базы данных в объекты ● Управляет подключениями к базе данных приложений ● Может создавать / изменять макет базы данных, если это разрешено Самая мощная особенность SQLAlchemy - это первый пункт: с учетом описания таблицы он отображает данные в таблицах в классы объектов, где каждый экземпляр объекта является строкой в таблице, и с ним можно работать как с классом или структурой. 3.3 Разработка одностраничного web-приложения. Во время обдумывания структуры проекта было принято решение разделить приложение на три микросервиса, каждый из которых развёрнут и запущен в отдельном Docker контейнере: smp_client - контейнер, отвечающий за клиентскую часть приложения, smp_app - контейнер, отвечающий за серверную часть приложения и smp_db - контейнер, отвечающий за базу данных (docker-compose.yml). Запуск контейнеров будет осуществляться при помощи bash-скрипта. Такое возможности решение запустить облегчит все развертывание контейнеры приложения одновременно, из-за обеспечит отказоустойчивость приложения, за счёт того, что при сбое в каком-либо контейнере другие контейнеры продолжат работу и даст возможность легче отлаживать приложение. 3.3.1 Клиентская часть web-приложения. В качестве фронтенд технологии для разработки одностраничного web-приложения был выбран фреймворк Vue с его UI библиотекой Vuetify для реализации Material Design. 49 Vue приложение находится в контейнере smp_client и начинает свой запуск с команды “npm run build”, которая при помощи пакетного менеджера собирает и оптимизирует приложение для дальнейшего развертывания. Родительским каталогом всего Vue приложения является каталог client, который включает в себя: каталог node_modules, который хранит все библиотеки, которые могут пригодиться в разработке; каталог public, который хранит все изображения и документы; каталог src, в котором написан весь код разработки; каталог templates, содержащий страницу, которая будет основной в случае отключения поддержки JavaScript на сайте; файл конфигурации babel.config.js; файл eslintrc.js для написания “чистого” кода; файлы с зависимостями package.json и package-lock.json; файл yarn.lock, который хранит точные версии зависимостей конкретного проекта. public В каталоге public находятся каталоги file и img с медиа файлами клиентской части приложения, а именно документы и изображения, и страница index.html, которую пользователь увидит, если в настройках его браузера отключена поддержка языка программирования JavaScript. В каталоге file находятся файлы лицензий и документов компании, а в каталоге img находятся изображения. src Каталог src содержит в себе код клиентского приложения. В нём находятся следующие каталоги и файлы: ● assets - каталог с SASS стилями ● components - каталог с Vue компонентами, использующимися в приложении ● middleware - каталог с middleware плагинами ● plugins - каталог с плагинами ● router - каталог с урлами и связанными с ними представлениями ● store - каталог с хранилищем ● views - каталог с представлениями 50 ● App.vue - родительский vue-файл, который является шаблоном для всего web-приложения. ● registerServiceWorker.js файл, - предназначенный для эффективного взаимодействия клиента с сервером в автономном режиме. Components Для упрощения разработки в Vue.js используется система компонентов. Компонент - это экземпляр Vue, который может быть использован внутри другого экземпляра Vue. При этом компоненты могут принимать параметры, хранимые в поле props. Это упрощает разработку программы и уменьшает избыточность кода. В приложении написаны следующие компоненты, расположенные в каталоге ui: ● AboutCompanySubmenu - Содержит подменю вкладки “О компании”. (рис. 1) Рисунок 1. подменю вкладки “О компании” ● ButtonUp - Содержит кнопку, возвращающую к верху страницы. (рис. 2) Рисунок 2. Кнопка «Вверх» ● CardLogo - Содержит логотип компании. (рис. 3) Рисунок 3. Логотип компании ● CardManagement - Содержит фото, имя и должность сотрудника компании. (Рис. 4) 51 Рисунок 4. Карточка сотрудника ● CardNews - Содержит карточку с новостями. (рис. 5) Рисунок 5. Карточка с новостью ● CardProduct - Содержит карточку с продуктом. (рис. 6) Рисунок 6. Карточка продукта ● CardsNews - Содержит список всех карточек с новостями. (рис. 7) Рисунок 7. Список карточек с новостями ● CardsWithNumber - Содержит карточку с цифрой и описанием того, что эта цифра значит. (рис. 8) 52 Рисунок 8. Карточка с цифрами ● CardWithSlogan - Содержит заголовок и подзаголовок представлений (views). (рис. 9) Рисунок 9. Карточка со слоганом ● ContentDocument - Содержит заголовок и ссылку на документ. (рис. 10) Рисунок 10. Компонент документа ● ContentEffect - Содержит информацию об уменьшении цены товара после реализации проекта. (рис. 11) Рисунок 11. Карточка реализации товара ● ContentNumeric - Содержит информацию о компании. (рис. 12) Рисунок 12. Карточка с достижениями компании 53 достижениях ● ContentProduct - Содержит изображение и характеристики выбранного продукта. (рис. 13) Рисунок 13. Характеристики продукта ● ContentText - Содержит заголовок и текст. (рис. 14) Рисунок 14. Компонент с заголовком и текстом ● FeedbackForm - Содержит форму для обратной связи. (рис. 15) Рисунок 15. Форма обратной связи ● Footer - Содержит подвал сайта. (рис. 16) 54 Рисунок 16. «Подвал» web-приложения ● LicenseSlider – Содержит слайдер с лицензиями. (рис. 17) Рисунок 17. Слайдер лицензий ● MainSlider - Содержит слайдер в шапке сайта для русской и английской версии. (рис. 18) Рисунок 18. Главный слайдер 55 ● PartnerShipSubmenu Содержит - подменю вкладки “Партнерство”. (рис. 19) Рисунок 19. Подменю вкладки «Партнерство» ● SliderEN - Содержит слайдер для английской версии сайта. (рис. 20) Рисунок 20. Слайдер для английской версии ● SliderRU - Содержит слайдер для русской версии сайта. (рис. 21) Рисунок 21. Слайдер для русской версии ● Submenu - Содержит кнопку для элементов подменю. (рис. 22) Рисунок 22. Кнопка для подменю ● ToolBar – содержит кнопки переключения языков. (рис. 23) Рисунок 23. кнопки переключения языков ● WorkForm - Содержит форму для резюме. (рис. 24) 56 Рисунок 24. Форма для резюме Компоненты подключаются через файл index.js, также расположенный в каталоге ui. middleware Каталог middleware содержит в себе middleware плагины, которые срабатывают при отправке запросов на сервер и получении ответов с сервера: ● admin.js - осуществляет проверку, является ли пользователь сайта администратором ● auth.js - осуществляет проверку, зарегистрирован ли пользователь сайта ● check-auth.js - удаляет зарегистрирован на сайте 57 токен пользователя, если он ● guest.js - осуществляет проверку, является ли пользователь сайта ● locale.js - определяет выбранный на сайте язык гостем Плагины admin.js, auth.js, check-auth.js, guest.js, locale.js пока не имеют применения, однако сделаны на случай если понадобиться расширить возможности сайта, например сделать интернет-магазин. plugins Каталог plugins содержит файлы: ● axios.js - библиотека для выполнения XMLHttpRequests в браузере, либо http запросов в Node.js. ● i18n.js - файл интернационализации, при котором приложение можно легко адаптировать под разные языки и народы. ● vuetify.js - файл, в котором прописано использование библиотеки vuetify. Router Каталог Router содержит файл routes.js, который прописывает и сопоставляет компоненты с путями запроса. Store Каталог Store хранит в себе глобальное хранилище данных, к которому могут обратиться из любого экземпляра Vue. Это хранилище реализовано при помощи библиотеки Vuex, которая является надстройкой для Vue. Vuex использует глобальное древо состояний, то есть один объект хранит в себе все глобальные состояния приложения. Под термином “Состояние” в JavaScript принято считать переменные, в которых хранятся данные о состоянии приложения или отдельных его компонентов. Для доступа к состояниям в Vuex используются специальные методы - гетеры. Они имеют доступ к состояниям и могут вернуть сами состояния или состояния, изменённые каким-либо образом. Для изменения состояний используются методы под названием мутации. Они могут изменять состояния, однако они не могут делать это асинхронно, что является 58 критичным недостатком для web-приложений. Для устранения этого недостатка используются специальные методы - действия. Действия обращаются к мутация и являются асинхронными, что позволяет изменять состояния асинхронно. Так же хранилище можно разбить на модули для облегчения разработки приложения. В каталоге Store находятся следующие каталоги, в каждом из которых находится отдельный модуль Vuex: ● auth - отвечает за аутентификацию и авторизацию пользователей. ● lang - отвечает за выбранный на сайте язык. ● mail - отвечает за показ ошибок при попытке отправить данные по электронной почте. ● news - отвечает за показ новостей. ● products - отвечает за показ продуктов. Также в каталоге store хранятся файлы index.js и mutation-types.js. Файл index.js отвечает за инициализацию хранилища vuex и динамическую загрузку модулей хранилища. Файл mutation-types.js содержит в себе мутации, используемые в модулях. views Представления (или views) это по сути те же самые компоненты, но функционируют предназначенные они для как страницы, работы с то есть это маршрутизатором. компоненты, Как правило представления могут иметь по несколько отдельных компонентов. В приложении написаны следующие представления, расположенные в каталоге views: ● 404.vue - выводит ошибку со стороны сервера. (рис. 25) Рисунок 25. Страница «Ошибка» ● AboutCompany.vue - выводит страницу «О компании». (рис. 26) 59 Рисунок 26. Страница «О компании» ● AllNews.vue - выводит страницу «Новости компании». (рис. 27) Рисунок 27. Страница «Новости компании» ● AnticorruptionPolicy.vue - выводит “Антикоррупционная политика”. (рис. 28) Рисунок 28. Страница “Антикоррупционная политика” ● Career.vue - выводит страницу «Карьера». (рис. 29) 60 страницу Рисунок 29. Страница «Карьера» ● Contacts.vue - выводит страницу «Контакты». (рис. 30) Рисунок 30. Страница «Контакты» ● Documents.vue - выводит страницу «Документы». (рис. 31) Рисунок 31. Страница «Документы» ● EcologySecurity.vue - выводит безопасность». (рис. 32) 61 страницу «Экологическая Рисунок 32. Страница «Экологическая безопасность» ● EffectivnessProject.vue - выводит страницу «Эффективность проекта». (рис. 33) Рисунок 33. Страница «Эффективность проекта» ● Main.vue - выводит главную страницу. (рис. 34) Рисунок 34. Главная страница ● Management.vue - выводит страницу «Руководство». (рис. 35) 62 Рисунок 35. Страница «Руководство» ● OurPartners.vue - выводит страницу «Наши партнеры». (рис. 36) Рисунок 36. Страница «Наши партнеры» ● OurProducts.vue - выводит страницу «Наши продукты». (рис. 37) Рисунок 37. Страница «Наши продукты» 63 ● Partnership.vue - выводит страницу «Партнерство». (рис. 38) Рисунок 38. Страница «Партнерство» ● ProductPage.vue - выводит страницу «Продукт» с определенным якорем. (рис. 39) Рисунок 39. Страница «Продукт» ● ProjectProducts.vue - выводит страницу «Продукты в проекте». (рис. 40) 64 Рисунок 40. Страница «Продукты в проекте» ● TypeOfActivities.vue - выводит страницу «Виды деятельности». (рис. 41) Рисунок 41. Страница «Виды деятельности» babel.config.js Файл babel.config.js хранит конфигурацию транскомпилятора Babel, который применяется для всего Vue приложения, включая каталог node_modules. eslintrc.js ESlint - это инструмент, с помощью которого можно анализировать качество кода, написанного на любом стандарте JavaScript. Он приводит код к единому стилю, помогает избежать глупых ошибок, умеет автоматически исправлять многие из найденных проблем и хорошо интегрируется со многими инструментами разработки. package.json и package-lock.json 65 Файл package.json содержит важную информацию для менеджера пакетов npm, например, название приложения, версию и пакеты, используемые в приложении. Файл package-lock.json создаётся во время установки пакетов. Он хранит информацию о версиях пакетов, чтобы избежать ошибок из-за изменений версий пакетов. yarn.lock Файл yarn.lock нужен прежде всего для того, чтобы не произошло проблем с новыми обновляются. Поэтому версиями имея зависимостей, этот файл которые пакетный периодически менеджер будет использовать в первую очередь те версии, что находятся в этом файле. 3.3.2 Серверная часть web-приложения. Для разработки серверной части проекта был выбран python фреймворк - Django из-за своей простоты и наличия большого количества готовых решений, а именно панели администрирования, REST Api и возможности работать с электронной почтой. Django приложение находится в контейнере smp_app. Запуск контейнера начинается не сразу после запуска docker-compose, а через десять секунд после разворачивания контейнера smp_db. Это сделано для того, чтобы не было ошибок при попытке подключения к базе данных до её запуска. После этого выполняются миграции моделей django и запускается сам сервер. В текстовом файле requirements.txt находятся все зависимости, используемые на стороне сервера. Django позволяет создавать внутри проекта приложения, которые отвечают за часть логики приложения. В разработанном проекте есть следующие вложенные приложения: ● app_core - приложение для авторизации и аутентификации пользователей, а также для соединения с базой данных. ● mail - приложение для взаимодействия с электронной почтой. 66 ● products - приложение для взаимодействия с продукцией. ● news - приложение для взаимодействия с новостями на сайте ● settings - приложение со всеми настройками на сайте. app_core Приложение app_core имеет следующие каталоги: helpers, managers, middleware, models, views. в Каталоге helpers находится файл db.py, создающее соединение с базой данных для ORM SQLAlchemy. Каталог managers содержит файл UserManager.py, созданный для возможности создавать новых пользователей. В нём находится класс UserManager.py, в котором определены три метода: _create_user, create_user, create_superuser. Метод _create_user является приватным, то есть хотя к нему можно обратиться вне класса, он для этого не предназначен. Метод _create_user принимает параметры для создания нового пользователя и отвечает за добавление его в базу данных. Метод create_user принимает параметры для создания нового пользователя и создает нового пользователя через метод _create_user, передавая ему необходимые параметры, при этом если в параметрах не указано, что он является суперпользователем, то он добавляется в create_superuser базу данных принимает как обычный параметры для пользователь. Метод создания нового суперпользователя и создает нового суперпользователя через метод _create_user, при этом если в параметрах указано, что он не является суперпользователем, то метод выдает ошибку. Каталог middleware имеет файл time_request_middleware.py, в котором описан класс TimeRequestMiddleware для анализа скорости обработки запросов. В Django middleware-это плагины, которые выполняются перед получением запроса или отправкой ответов. Класс TimeRequestMiddleware имеет Метод три метода: __init__ __init__, отвечает за process_request инициализацию и, process_response. экземпляра класса TimeRequestMiddleware, Метод process_request запоминает время прибытия 67 запроса. Метод process_responce Вычисляет время выполнения запроса, вычислив из времени отправки ответа время прибытия запроса. Каталог migrations содержит в себе миграции модели User.py, сформированные позволило при помощи SQLAlchemy, упростить процесс разработки применение приложения. миграций Миграции применяются при запуске контейнера smp_app. Каталог models имеет файл User.py, который описывает модель пользователя для авторизации и аутентификации, а также ее методы и свойства. Модель имеет следующие поля: ● uid - идентификатор пользователя. ● login - login пользователя для авторизации. ● first_name - имя пользователя. ● last_name - фамилия пользователя. ● sir_name - отчество пользователя (если имеется). ● is_active - состояние активность пользователя на сайте. ● staff - права пользователя (администратор или обычный пользователь). ● admin - наличие прав superuser. ● created - дата создание пользователя. Свойство get_full_name возвращает полное имя пользователя (имя и фамилию). Свойство get_short_name возвращает только имя пользователя. Свойство is_staff сообщает о том, является ли пользователь администратором или обычным пользователем. Свойство is_admin говорит о том, является ли пользователь superuser. Каталог views содержит файл auth_view.py, в котором хранятся 3 класса: GetAuthToken, Logout, Message. 68 Класс GetAuthToken предоставляет возможность авторизации пользователей на клиентской части приложения, которая может будет использоваться в будущем. Класс Logout дает возможность выхода из системы, то есть токен пользователя во время сессии удаляется. Класс Message позволяет обмениваться сообщениями между пользователями, используя GET и POST запросы. Mail Django-приложение mail имеет файл views.py, который содержит классы, описывающие логику и работу API форм web-приложения. Класс FeedBack описывает работу POST запроса формы обратной связи. Класс Work описывает работу POST запроса формы для отправки резюме. Products Приложение Products содержит два каталога migrations и views, а также два файла models.py. и admin.py. Файл models.py содержит модель данных продуктов под названием Products. Модель имеет следующие параметры: ● uid - уникальный идентификатор продукта, ● type - тип продукта, ● mnn - международное непатентованное наименование, ● img-изображение продукта, ● dosage - дозировка продукта, ● form_of_release - форма выпуска, ● product_conditions - условия отпуска, ● farm_group - фармако-терапевтическая группа, ● price - цена товара, instruction - файл с инструкцией к товару, ● analog_name - наименование аналога, ● analog_description - описание аналога, 69 ● analog_price - цена аналога, ● en_mnn - английское международное непатентованное наименование, ● en_dosage - дозировка товара на английском языке, ● en_form_of_release - форма выпуска на английском языке, ● en_farm_group - фармако-терапевтическая группа на английском ● en_analog_name - наименование аналога на английском языке, ● en_analog_description - описание товара на английском. языке, В каталоге views находится файл products.py, отвечающий за API, реализованное с помощью Django REST framework. Файл состоит из трёх методов get_img_url, get_instruction_url и get_products_schema, а также одного класса ProductsList. Из-за того, что данные, изображения и инструкции хранятся в виде файлов, но к ним можно обратиться через URL, были написаны методы get_img_url и get_instruction_url, которые позволяют это сделать. Метод get_img_url принимает два параметра: абсолютный url приложения products и поле img из модели Products. Поле img имеет тип ImageField, что позволяет получить локальный url для доступа к изображению. В методе из абсолютного урла вычитается часть, отвечающая за доступ к приложению Products, затем прибавляется локальный url изображения, чтобы получить полный url изображения. Похожим образом работает метод get_instruction_url. Метод get_products_schema описывает схему REST запроса, которая позволит при расширении приложения ввести дополнительные возможности. Схема имеет следующие поля: ● filters - список фильтров, который в будущем позволит отфильтровать выборку значений. ● limit - в будущем позволит выбрать определенное значение продуктов для отображения на клиенте. 70 ● offset - в будущем позволит осуществить смещение по выборке продуктов ● token - в будущем позволит осуществлять выборку в зависимости от прав пользователя. Класс ProductsList формирует JSON ответ на post запрос списка продуктов Каталог migrations хранит миграции базы данных модели Products. Файл admin.py добавляет возможность взаимодействовать с продуктами в панели администрирования. News В приложении news находятся каталоги migrations и views, а так же два файла admin.py и models.py. Migrations содержит все миграции базы данных модели News, а views хранит файл news.py, который описывает логику приложения. В файле news.py хранятся методы и классы, отвечающие за логику и API Django-приложения. Метод get_img_url возвращает URL изображений новости для работы с ними на клиентской части приложения (подобно методу get_img_url из Django-приложения products). Метод get_news_schema идентичен методу get_products_schema из Django-приложения products, который описывает схему REST запросов. Класс NewsList создает JSON-файл со списком всех новостей, отсортированных по дате создания и отсылает их по POST запросу. В файле models.py описываются параметры таблицы news базы данных smp, где: ● created - дата создания новости. ● updated - дата обновления новости. ● title - заголовок новости. ● anons - предварительный текст новости. ● text - текст новости. 71 ● img - изображение, приложенное к новости. ● en_title - заголовок новости на английском. ● en_anons - предварительный текст новости на английском. ● en_text - текст новости на английском. Файл admin.py добавляет возможность взаимодействовать с новостями в панели администрирования. Settings В файле __init__.py приложения settings описывается создание каталога media, в котором хранятся все изображения из таблиц news и products базы данных smp. Также там хранится SECRET_KEY для работы с базой данных в ORM SQLAlchemy. Файл apps.py определяет установленные приложения в проекте. Файл auth.py устанавливает валидацию для аутентификации пользователей. В файле database.py описывается база данных и используемая СУБД. В файле mail.py описывается конфигурация электронной почты, на которую будут идти все данные с форм. Панель администрирования В Django есть встроенный инструмент администрирования Django Admin, позволяющий добавлять, редактировать или удалять данные в базе данных. Доступ к панели администрирования имеют лишь суперпользователи, в случае этого проекта, это лишь единственный пользователь с логином Admin и паролем arst234nhei. (рис. 42) 72 Рисунок 42. Панель администрирования web-приложения 3.3.3 База данных web-приложения. В качестве базы данных проекта было решено выбрать СУБД PostgreSQL из-за её надёжности и опыта создания базы данных в ней. Альтернативой рассматривались SQLServer и MongoDB, но так как SQLServer является коммерческой разработкой Microsoft и требует покупку лицензии, а с MongoDB отсутствовал достаточный опыт работы, то был выбран PostgreSQL в качестве основной СУБД. База данных находится в контейнере. Для возможности взаимодействовать с базой данных в файле docker-compose.yml создаются три тома: data, где хранится сама база данных; docker-entrypoint-initdb.d, в котором хранятся файлы конфигурации и стартовые скрипты; backup, предназначенный для резервных копий базы данных. При развертывании контейнера, происходит проверка данных в папке data. Если их нет, то происходит инициализация, то есть создается база данных smp и выполняются все стартовые SQL скрипты, находящиеся в папке docker-entrypoint-initdb.d, и только после этого база данных готова к работе. В качестве стартовых скриптов могут быть использованы резервные копии базы данных. В одном из стартовых скриптов для безопасности изменяется пароль суперпользователя postgres и создаётся пользователь в таблице users с правами доступа к панели администрирования сервера. 73 Для быстрого создания резервной копии базы данных был написан bash-скрипт create_backup.sh. Он создает резервную копию в виду SQL скрипта и помещает ее в папку backup, которая может быть использована как стартовый скрипт при инициализации базы данных. В папке data, где хранятся все данные, создается база данных smp. При помощи стартовых скриптов (или при помощи ORM SQLAlchemy в их отсутствие) в ней создаются таблицы: users - таблица, в которой хранятся все суперпользователи панели администрирования сервера; news - таблица для новостей; products - таблица, в фармацевтической компании. 74 которой хранится продукция ЗАКЛЮЧЕНИЕ Итак, рассмотрев тему «Технологии разработки одностраничных WEB-приложений», можно сделать вывод, что SPA-приложения с каждым годом занимают все большую часть рынка web-разработки. Давая возможность поддерживать функции и методы на стороне клиента, которые при этом не требуют каждый раз перезагрузки страницы, разработчики упрощают себе процесс создания проекта и улучшают взаимодействие пользователя с web-приложением. Также помимо этого SPA позволяет реализовывать расширенные функции приложения, такие как: отображение понятного URL-адреса в адресной строке, благодаря чему пользователь может вставлять логически понятные пути в приложении; возможность перемещаться между вкладками с помощью кнопок браузера «Вперед» и «Назад», давая предсказуемый результат. Но среди таких весомых преимуществ найдется место и для недостатков, которые могут помешать в процессе разработки или вовсе прекратить работу над продуктом. Чтобы этого избежать нужно внимательно подходить к данному вопросу, исследуя технологии доступные для разработки и выбирая команду разработчиков. В данной работе были исследованы современные web-технологии, предназначенные для создания одностраничных web-приложений и было разработано одностраничное web-приложение для компании «СмолМедПрепараты». С помощью данного проекта были реализованы следующие возможности, которые полностью соответствуют требованиям реализации данного web-приложения: Обратная связь с пользователем, посредством внедрения форм. Адаптивный дизайн для удобства пользования приложением. Панель администрирования для написания новостей и добавления продукции компании. Интернационализация, позволяющая отображать контент не только на русском языке, но и на английском. 75 Привлекательный дизайн для отображения всей необходимой информации. Показ лицензий компании в слайдере. Связь с компаниями для инвесторов. 76 потенциальных работников и СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ 1. Миковски, М. С. Разработка одностраничных веб-приложений / Миковски М. С., Пауэлл Д. К. – М.: ДМК Пресс, 2014. – 512 с. 2. Фримен, А. Angular для профессионалов / Фримен А. – СПб.: Питер, 2018. – 800 с. 3. Тиленс, Т.М. React в действии / Тиленс Т.М. – СПб.: Питер, 2019. – 368 с. 4. Хэнчетт, Э. Vue.js в действии. / Хэнчетт Э., Листуон Б. – СПб.: Питер, 2019. – 304 с. 5. Мациевский, Н.С. Реактивные веб-сайты. Клиентская оптимизация в алгоритмах и примерах : учебное пособие / Н.С. Мациевский, Е.В. Степанищев, Г.И. Кондратенко. – 3-е изд. (эл.) - М.: Национальный Открытый Университет «ИНТУИТ» ; Ай Пи Ар Медиа, 2020. – 335 с. – Текст : электронный. 6. Новиков, Б.А. Основы технологий баз данных: учебное пособие / Б. А. Новиков, Е. А. Горшкова, Н. Г. Графеева; под ред. Е. В. Рогова. — 2-е изд. — М.: ДМК Пресс, 2020. — 582 с. 7. Шеннон, Брэдшоу MongoDB: полное руководство. Мощная и масштабируемая система управления базами данных / Шеннон Брэдшоу, Йон Брэзил, Кристина Ходоров, пер. с англ. Д. А. Беликова – М.: ДМК Пресс, 2020. – 540 с. 8. Кочер, П. С. Микросервисы и контейнеры Docker / Кочер П. С., пер. с анг. А. Н. Киселева. – М.: ДМК Пресс, 2019. – 240 с. 77
