Главная Научные журналы «Интернаука» Научный журнал «Интернаука» №36(212) ВЫБОР ТЕХНОЛОГИЧЕСКОГО СТЕКА ДЛЯ IT-ПРОЕКТА

ВЫБОР ТЕХНОЛОГИЧЕСКОГО СТЕКА ДЛЯ IT-ПРОЕКТА

Опубликовано в журнале: Научный журнал «Интернаука» № 36(212)
Рубрика журнала: 3. Информационные технологии
DOI статьи: 10.32743/26870142.2021.36.212.303217
Библиографическое описание
Плетнев А.В. ВЫБОР ТЕХНОЛОГИЧЕСКОГО СТЕКА ДЛЯ IT-ПРОЕКТА // Интернаука: электрон. научн. журн. 2021. № 36(212). URL: https://internauka.org/journal/science/internauka/212 (дата обращения: 19.04.2024). DOI:10.32743/26870142.2021.36.212.303217

Авторы

Плетнев Андрей Владимирович

ВЫБОР ТЕХНОЛОГИЧЕСКОГО СТЕКА ДЛЯ IT-ПРОЕКТА

Плетнев Андрей Владимирович

независимый исследователь, директор ТОО «SimCo Soft», руководитель группы разработки ТОО «OneBill»,

Республика Казахстан, г. Алматы

 

CHOICE OF TECH STACK FOR IT PROJECT

Andrey Pletnev

Independent researcher, CEO «SimCo Soft» LLP, Team lead «OneBill» LLP,

Republic of Kazakhstan, Almaty

 

АННОТАЦИЯ

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

ABSTRACT

This article provides a practical guide to choosing the most convenient technology stack from the point of view and experience of the author for the implementation of an IT project. Variants of technological solutions are offered for use, their advantages and disadvantages are given, also arguments in favor of the solutions recommended by the author.

 

Ключевые слова: web-технологии, выбор языка программирования, backend, frontend, выбор базы данных, Debian, клиент-сервер, протокол обмена данными.

Keywords: web-technologies, choice of programming language, backend, frontend, choice of DB engine, Debian, client-server, data exchange protocol.

 

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

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

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

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

  1. топология системы (клиент-сервер, распределенная система и т.п.);
  2. тип операционной системы на сервере;
  3. типы баз данных, используемых на стороне сервера;
  4. языки программирования, используемые для разработки серверных и клиентских приложений;
  5. архитектура серверных приложений (монолит, микро-сервисы);
  6. протокол обмена данными между компонентами системы (RestAPI, xml, json, SOAP, Protocol Buffers, gRPC).

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

  1. стоимость владения проектом. Сюда входит:
    • стоимость лицензии на операционную систему сервера(ов);
    • стоимость лицензии на базу данных;
    • стоимость лицензий разработчика для сред и\или языков разработки;
    • стоимость хостинга проекта: аренда сервера, поддержка доменного имени, поддержка сертификата SSL, лицензия на панель управления хостингом;
    • стоимость поддержки магазинов клиентских приложений для мобильных устройств.
  2. надежность и безопасность реализованной системы;
  3. возможность масштабирования проекта в будущем;
  4. доступность специалистов по разработке программного обеспечения и специалистов по сопровождению проекта на рынке труда и их стоимость.

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

Топология системы. В контексте этой статьи мы будем рассматривать топологию вида клиент-сервер [4] как наиболее распространенную. Преимуществами данного выбора являются:

  1. отсутствие дублирования кода программы-сервера программами-клиентами;
  2. централизация хранения данных;
  3. в большинстве случаев все вычисления производятся на стороне сервера что снижает требования к производительности устройства клиента;
  4. сервер и данные на нем, как правило, защищены гораздо лучше большинства клиентов;
  5. на сервере проще организовать распределение и контроль прав доступа пользователей к данным;

К недостаткам этой топологии можно отнести:

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

Тип операционной системы на сервере. Я категорически рекомендую использовать одну из операционных систем из семейства Linux. В своих проектах я и мои команды используем Debian Linux – я рекомендую именно его, потому что:

  1. Debian разрабатывается с 1993 года;
  2. Debian разрабатывается сообществом независимых разработчиков, а потому совершенно бесплатен;
  3. Debian стабилен и безопасен;
  4. Debian предоставляет регулярные обновления системы;
  5. Debian имеет наибольшее среди всех дистрибутивов Linux хранилище пакетов программ – более 60 000 свободно распространяемых пакетов;
  6. NASA использует систему Debian на рабочих местах космонавтов на МКС [5]. Также NASA применяло систему Debian в экспериментах на шаттле Колумбия [12];
  7. Debian используется в университетах, правительственных, коммерческих и некоммерческих организациях по всему Миру [21];
  8. Debian выбран многими поставщиками и разработчиками операционных систем (более 100) как основа для собственных дистрибутивов операционных систем. Наиболее популярные и известные из них это Ubuntu, Kali Linux, Linux Mint, ASLinux и Raspberry Pi OS (ранее Raspbian – ОС для одноплатных мини-компьютеров Raspberry Pi);
  9. Debian эффективно поддерживает драйверы для большого количества оборудования, а также все распространенные архитектуры процессоров, в том числе и устаревшие, что позволяет стартапу на первых порах значительно снизить затраты на собственную серверную инфраструктуру, если она необходима;
  10. практически все хостинговые компании предоставляют дистрибутив Debian для развертывания на арендуемых у них серверах (как виртуальных, так и выделенных);
  11. Debian, как и прочие Unix-подобные ОС, при правильной настройке не нуждаются в антивирусном программном обеспечении.

Наряду с Debian Linux и Ubuntu Server достаточно популярными свободно распространяемыми дистрибутивами серверной операционной системы являются CentOS Linux и Fedora Linux, которые основаны на коммерческом дистрибутиве Red Hat Enterprise Linux (RHEL). Вам решать, какой из этих дистрибутивов использовать – описываемые ниже в этой статье технологические решения будут одинаково хорошо работать на всех этих системах, но некоторые системные настройки в Debian Linux и Ubuntu Server, на мой взгляд, реализованы удобнее и проще. В частности: конфигурация firewall, сетевых интерфейсов и сетевой маршрутизации, конфигурация запуска служб, конфигурация proxy-сервера nginx и т.д.

Напоследок несколько советов по установке и настройке серверной ОС:

  1. при первичной установке операционной системы на сервер не устанавливайте никакие графические оболочки – на сервере, из доступных интерфейсов пользователя, должна быть только командная строка (в установщике Debian в самом начале выберите опцию установки Minimal Setup) – это в значительной степени освободит ресурсы сервера для ваших задач и сократит время установки ОС;
  2. подключайте только официальные stable-репозитории пакетов Debian;
  3. сразу после установки ОС и подключения репозиториев выполните обновление системы;
  4. для удобства администрирования сервера установите файловый менеджер Midnight Commander (mc) и диспетчер процессов htop;
  5. создайте учетную запись для пользователя, который будет администрировать сервер. По соображениям безопасности не используйте в качестве имени для этого пользователя распространенные имена, например, administrator и всевозможные его сокращения;
  6. установите для SSH-сервера порт для входящего соединения, отличный от 22, сгенерируйте на своем рабочем компьютере SSH-ключи и скопируйте публичный ключ в домашнюю папку созданного ранее пользователя на сервере и, после проверки возможности подключения к SSH-серверу со своего компьютера в режиме авторизации по SSH-ключу, отключите на SSH-сервере возможность удаленной авторизации по паролю, а также, при желании, заблокируйте удаленную авторизацию корневого пользователя (root);
  7. настройте firewall на запрет входящих соединений по всем портам кроме тех, на которых будет работать Ваш сервис и SSH-сервер;
  8. ни при каких обстоятельствах не открывайте доступ к Вашей базе данных из вне! Служба сервера базы данных строго должна слушать свой порт на localhost’е. При необходимости доступа к Вашей базе из вне используйте SSH-туннелированные соединения;
  9. для доступа к файлам на сервере используйте протокол SFTP – ключи SSH для этого у Вас уже есть. Для этих целей хорошо подходит FTP-клиент FileZilla – он бесплатен и удобен в использовании, а также для него регулярно выходят новые версии, в которых добавляется новый функционал;
  10. создайте новую группу пользователей и пользователя в этой группе без прав удаленной авторизации в системе и без домашнего каталога. Выполняйте запуск своих сервисов от имени этого пользователя. Это позволит уберечь ОС Вашего сервера от разрушительных действий при потенциальном вторжении злоумышленника, при наличии уязвимостей в коде Вашего сервиса. Не забудьте назначить соответствующие права доступа созданному пользователю к каталогам и файлам, с которыми должен будет работать Ваш сервис.

В этом перечне даны рекомендации по самым базовым настройкам системы. Для более подробного изучения вопросов практики самостоятельного администрирования и настроек безопасности сервера рекомендую обратиться к соответствующей литературе [6].

База данных.

В настоящее время существует 3 основных типа баз данных:

  1. Реляционные системы управления базами данных – РСУБД или SQL-базы данных;
  2. Документно-ориентированные базы данных – ДОБД или noSQL;
  3. Резидентные базы данных – хранят данные в виде пар ключ-значение в оперативной памяти сервера. Данный вид БД также относится к noSQL.

РСУБД и ДОБД используются для длительного хранения структурированных данных на дисковой памяти сервера. При этом SQL-базы данных, в сравнении с noSQL-базами данных, обеспечивают более строгую типизацию структуры и контроль целостности данных, а также предоставляет гораздо более обширный функционал для выполнения манипуляций с данными.

В качестве РСУБД для Вашего проекта я рекомендую использовать PostgreSQL. PostgreSQL – это популярная бесплатная, кроссплатформенная, надежная и быстрая объектно-реляционная СУБД [14], которая наиболее часто используется для:

  1. хранение и регистрация событий;
  2. системы управления документами и контентом;
  3. мобильные приложения;
  4. справочные системы;
  5. разнообразные информационные системы корпоративного уровня;
  6. учетно-биллинговые и платежные системы и т.п.

Данные в РСУБД хранятся в виде таблиц с заранее определенной структурой данных (столбцов) и каждая запись (строка) в такой таблице имеет тот-же набор столбцов, что и остальные записи в этой таблице. Такие таблицы могут быть связаны между собой и образовывать сложные иерархические структуры данных. Используйте PostgreSQL в проектах, где:

  1. необходима работа в смешанной нагрузке на чтение\запись;
  2. требуется хранение данных строго определённой структуры;
  3. предполагается хранение и использования большого объема нормализованных данных;
  4. необходимо связывание данных (JOIN);
  5. необходимо использовать полнотекстовый поиск;
  6. необходим контроль целостности структуры данных;
  7. планируется вынести часть бизнес-логики серверного приложения в базу данных (хранимые процедуры, функции и триггеры);
  8. необходимы надежные механизмы транзакций и репликации;
  9. требуется легкая расширяемость и масштабируемость.

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

ДОБД функционально более просты и чаще всего используются для:

  1. хранение и регистрация событий;
  2. системы управления документами и контентом;
  3. игры;
  4. данные мониторинга, датчиков;
  5. мобильные приложения;
  6. хранилище операционных данных веб-страниц (например, хранение комментариев, рейтингов, профилей пользователей, сеансы пользователей).

Данные ДОБД хранятся в так называемых коллекциях. Коллекция – отдаленный аналог таблицы в РСУБД, не имеющая колоночной структуры: данные в коллекции хранятся в виде множества JSON-документов. Разработчик должен позаботиться о том, чтобы каждая коллекция в ДОБД хранила структурно однотипные документы.

Наиболее популярной и рекомендуемой мною для использования ДОБД является MongoDB [13]. Используйте MongoDB, в проектах, где:

  1. необходима работа в смешанной нагрузке на чтение\запись;
  2. необходима гибкость структуры данных, либо структура объектов до конца не определена;
  3. предполагается хранение и использования большого объема слабоструктурированных данных;
  4. нет необходимости связывания данных (JOIN);
  5. требуется легкая масштабируемость.

MongoDB не подходит для использования в проектах, где:

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

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

Стоит отметить, что последние версии PostgreSQL (начиная с версии 11) также очень хорошо поддерживают работу со слабоструктурированными данными в форматах JSON и XML, имеет развитый функционал noSQL и по скорости работы не уступает MongoDB, а по некоторым тестам и вовсе превосходит ее.

Третий тип баз данных, упомянутый выше, как Резидентные СУБД, используется для кратковременного хранения данных в оперативной памяти сервера. Такой тип баз данных наиболее часто используется для построения кэшей и брокеров сообщений. Наиболее популярной БД этого типа является Redis [19]. Все данные Redis хранит в виде словаря, в котором ключи связаны со своими значениями. Одно из ключевых отличий Redis от других хранилищ данных подобного рода заключается в том, что значения этих ключей не ограничиваются строковым типом данных. Поддерживаются следующие абстрактные типы данных: строки, списки, множества, хеш-таблицы, упорядоченные множества. Используйте Redis в своем проекте, когда серверному приложению необходимо снизить нагрузку на основную БД путем кэширования данных, таких как:

  1. назначенные пользователям права доступа, их сессии и данные профилей;
  2. список пользователей онлайн;
  3. разнообразные счетчики и данные оперативной статистики Вашей системы;
  4. разнообразные очереди: сообщения, флаги состояний, команды и т.п.

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

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

Для разработки серверных приложений уже более пяти последних лет я и мои команды используем язык программирования Go, также называемый GoLang [8]. Именно его я и рекомендую для разработки Ваших проектов. К преимуществам использования языка Go можно отнести:

  1. GoLang является многопоточным компилируемым и кроссплатформенным системным языком программирования. Компилятор позволяет разработчику, работая на одной платформе (например, MS Windows), выполнять компиляцию для другой платформы (например, Linux);
  2. супербыстрая компиляция проекта;
  3. по производительности почти не уступает языку C и С++;
  4. строгая статическая типизация переменных;
  5. низкая требовательность к объему оперативной памяти;
  6. большая собственная библиотека и огромное количество библиотек, разрабатываемых сообществом, доступных на github, позволяют разработчику решать широчайший круг задач;
  7. возможность подключения библиотек на C и C++;
  8. простота реализации параллельных вычислений;
  9. наличие встроенного автоформатирования кода;
  10. простота языка обеспечивает достаточно низкий порог вхождения в его экосистему: на моих глазах в разное время два разработчика frontend с уровнем ниже среднего осваивали Go всего за пару недель до того уровня, чтобы брать в разработку backend, переходя тем самым в разряд fullstack разработчиков.

В настоящее время Go – один из самых востребованных языков программирования и продолжает набирать популярность во всем Мире. Вот список некоторых компаний, которые переходят или уже перешли на разработку своих сервисов на языке Go: Alibaba, Google, Intel, IBM, PayPal, Slack, Tesla, Uber, Twitch, Dropbox, 2GIS, Mail.RU, Avito, Ozon, Yandex, ВКонтакте и многие другие [9], а также многочисленные стартапы, о которых нам только предстоит узнать. Также следует упомянуть, что на языке Go написан используемый и любимый всеми Docker [10].

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

  1. платежные системы;
  2. системы процессинга, агрегации и фискализации платежей;
  3. учетно-биллинговые системы для расчетных центров коммунальных услуг;
  4. системы управления очередями;
  5. системы управления документооборотом корпоративного уровня;
  6. backend для разнообразных мобильных и web-приложений.

Как упоминалось выше, Go имеет обширную библиотеку на github, которая позволяет реализовать весь необходимый функционал для Вашего проекта. Основными библиотеками для построения любого backend являются библиотека для реализации http-сервера и библиотека, обеспечивающая взаимодействие с базой данных. Для реализации http-сервера я рекомендую использовать библиотеку echo (echo.labstack.com). Последние 4 года своей работы я использую эту библиотеку, потому что она:

  1. быстрая, надежная и безопасная;
  2. регулярно получает обновления;
  3. хорошо документирована;
  4. имеет удобный роутер с возможностью группировки и умной приоритизации маршрутов;
  5. имеет встроенные middleware (CORS, GZip, JWT, Prometheus, Recover, Rewrite и многие другие) и дает возможность писать собственные, расширяя функциональность разрабатываемого web-сервиса;
  6. дает возможность писать собственные обработчики ошибок уровня протокола HTTP;
  7. поддерживает привязку данных, полученных в запросе (request payload data binding) в форматах JSON, XML или form-data;
  8. поддерживает response всех необходимых форматов: JSON, XML, HTML, File, Attachment, Inline, Stream или Blob;
  9. поддерживает работу с WebSocket’ами;
  10. поддерживает Server Side Rendering (SSR) и собственный формат шаблонов – думаю, что эта функция может оказаться полезной для тех, кто хочет построить собственную CMS на базе echo. В иных случаях, на мой взгляд, поддержка SSR бесполезна;
  11. имеет поддержку SSL, а также автоматическую установку TLS-сертификатов безопасности «Let's Encrypt».

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

  1. для PostgreSQL используйте pgx (github.com/jackc/pgx). Также стоит упомянуть о такой библиотеке, как GORM (github.com/go-gorm/gorm) – используйте ее, если в недостаточной степени владеете языком SQL-запросов и\или структура Вашей БД в достаточной степени проста;
  2. для MongoDB используйте mongo-driver (go.mongodb.org/mongo-driver/mongo);
  3. для Redis используйте go-redis (github.com/go-redis/redis).

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

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

  1. логирование событий сервиса;
  2. отправка уведомлений пользователям сервиса (e-mail, sms и т.п.);
  3. сбор метрик работы сервиса для анализа его производительности со стороны сети;
  4. сбор данных о состоянии оборудования сервера (загрузка ядер ЦП, объем свободной\занятой оперативной и дисковой памяти, количество запущенных процессов и т.п.);
  5. встроенный планировщик заданий и т.д.;

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

  1. количество звезд, форков и пул-реквестов – чем больше, тем библиотека популярнее;
  2. наличие спонсора у проекта – есть – хорошо, а нет – ничего страшного;
  3. дата последнего коммита или релиза – чем новее, тем лучше;
  4. количество закрытых issues по отношению к открытым – чем больше, тем лучше – это показатель активности команды разработки библиотеки.

Архитектура серверного приложения.

В настоящее время наиболее широкое распространение получили два вида архитектуры серверных приложений: монолитная и микросервисная. Оба эти вида имеют ряд достоинств и недостатков. Итак, давайте по порядку…

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

  1. уровень абстракции сетевого взаимодействия с клиентскими приложениями (API);
  2. уровень бизнес-логики;
  3. уровень абстракции данных и доступа к хранилищам данных;
  4. прочие вспомогательные функции сервиса.

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

  1. быстрота разработки;
  2. простота тестирования и отладки;
  3. простота развертывания и эксплуатации;
  4. масштабирование достигается путем размещения балансировщика нагрузки перед несколькими экземплярами Вашего серверного приложения.

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

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

Микросервисная архитектура представляет собой совокупность слабо связанных между собой сервисов, которые взаимодействуют между собой для решения общей бизнес-задачи [7]. Каждый из сервисов внутри микросервисной архитектуры несет свой уникальный функционал и имеет свое хранилище данных. Например: один сервис обслуживает запросы авторизации пользователей, второй реализует API для клиентских приложений, третий занимается регистрацией событий системы (логирование), четвертый обеспечивает рассылку уведомлений и так далее. Между собой такие сервисы взаимодействуют посредством обмена сообщениями по одному из выбранных протоколов (RestAPI, gRPC и пр.). Именно поэтому такая архитектура и была названа Микросервисной, так как в этом контексте «микро» означает ограниченную функциональность каждого такого сервиса, а не его физический размер.

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

  1. модульность инфраструктуры приложения – по принципу «разделяй и властвуй»;
  2. возможность более четкого разделения процесса разработки внутри команд: например, один программист – один сервис;
  3. нет необходимости останова всех сервисов производственной среды для обновления одного из них;
  4. хорошо спроектированная распределенная система переживет сбой одного сервиса;
  5. внутри протокола межмодульного взаимодействия можно организовать очереди сообщений. Когда сервис, принимающий сообщение, недоступен, отправляющий сервис должен ставить неотправленное сообщение в очередь. Когда принимающий сервис возобновит свою работу, он примет и обработает все не полученные до этого момента сообщения.

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

  1. более сложная, в сравнении с монолитом, реализация взаимодействия между сервисами;
  2. более затруднительное, в сравнении с монолитом, взаимодействие при тестировании;
  3. множество микросервисов сложнее в эксплуатации;
  4. может потребоваться больше оборудования при масштабировании;
  5. более сложное координирование команд разработки в случаях, когда изменения касаются нескольких сервисов одновременно;
  6. в большом проекте может понадобиться дополнительный специалист, который будет заниматься поставками модулей системы в производственную среду и управлять инфраструктурой этой среды – такой специалист называется DevOps.

Тут я могу порекомендовать идти по пути эволюционного развития проекта:

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

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

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

  1. web-приложения для настольных и мобильных браузеров – используйте React [3] или VueJS [20];
  2. мобильные устройства от компании Apple (iPhone и iPad) – используйте язык Swift, пришедший на замену Objective-C;
  3. мобильные устройства на базе ОС Android – используйте Java или Kotlin;

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

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

  1. процесс отнимает много времени;
  2. любое изменение, внесенное в приложение, потребует его повторной публикации в магазинах приложений AppStore и PlayMarket;
  3. требуется 2 разработчика отдельно для iOS и для Android, либо один разработчик-универсал, которому потребуется вдвое больше времени на разработку под обе платформы.

Для сокращения времени разработки мобильных приложений можно прибегнуть к кроссплатформенным библиотекам, таким как React Native - это кроссплатформенный фреймворк с открытым исходным кодом для разработки нативных мобильных и настольных приложений на JavaScript и TypeScript, созданный Facebook, Inc. React Native поддерживает такие платформы как Android, Android TV, iOS, macOS, Apple tvOS, Web, Windows и UWP, позволяя разработчикам использовать возможности библиотеки React вне браузера для создания нативных приложений, имеющих полный доступ к системным API платформ [16].

Протокол обмена данными.

Наиболее широкое распространение в настоящее время получили следующие протоколы обмена данными: Rest, Protocol Buffers и gRPC.

Rest (также часто называемый RestAPI) по сути, являясь набором правил по организации обмена данными между компонентами системы, представляет собой согласованный набор ограничений, учитываемых при проектировании распределённых гипермедиа-систем [1][17]. Компоненты Rest взаимодействуют по принципу клиент-сервер. Чаще всего внутри правил Rest обмен данными производится поверх протокола HTTP в формате JSON, реже XML и еще реже в других форматах. Преимуществами Rest являются:

  1. простота, надежность и производительность;
  2. достаточно простая масштабируемость и расширяемость;
  3. легкость внесения изменений;
  4. возможность использования произвольных форматов обмена данными, отличными от JSON и XML;
  5. возможность использования шифрования передаваемых данных.

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

Protocol Buffers (также называемый protobuf) – протокол передачи структурированных данных в бинарном виде, разработанный компанией Google как альтернатива формату XML. Отличительной особенностью Protocol Buffers является то, что программист сначала должен создать .proto-файл с описанием структур данных (форматов сообщений), которые будут участвовать в процессе обмена данными. После этого .proto-файл необходимо скомпилировать отдельно для каждого языка программирования, на котором написаны серверное и клиентские приложения. При этом выполняется генерация классов или структур данных и кода методов сериализации и десериализации данных [15]. GoLang, JavaScript, Swift и Java, выбранные нами в качестве языков программирования нашего технологического стека, имеют компиляторы .proto-файлов.

Достоинствами Protocol Buffers являются:

  1. единый формат .proto-файлов, имеются компиляторы для большинства популярных языков программирования;
  2. поддержка версионности протоколов;
  3. бинарная сериализация и, как следствие, компактный формат сообщения;
  4. встроенные правила валидации данных.

К недостаткам-же можно отнести следующее:

  1. трудности с интерпретацией прослушиваемых сообщений при отладке;
  2. без знания схемы очень тяжело разобрать (бинарный̆ формат данных, внутренне не однозначен, требуется схема для разбора) – может также являться и достоинством Protocol Buffers в некоторых ситуациях;
  3. включение GZip на сервере с JSON дает тот-же объем трафика. Справедливости ради стоит отметить, что включение GZip немного снижает быстродействие.

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

gRPC – протокол удаленного вызова процедур, также разработанный компанией Google. В качестве языка описание интерфейсов gRPC, также как и Protocol Buffers, используются .proto-файлы [11]. В то время, как Protocol Buffers является просто компактным бинарным протоколом обмена данными, gRPC предоставляет удобную реализацию вызова удаленных процедур, имеет синхронный и асинхронный режимы, а также механизмы гарантирования доставки.

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

Отдельного упоминания заслуживает протокол обмена данными SOAP [18]. На сегодняшний день SOAP считается чрезмерно избыточным и устаревшим. Я не рекомендую его использование в новых проектах. Тем не менее некоторые банки, платежные и иные организации продолжают его использование на своих web-сервисах. Если Вы планируете разработку своего проекта, которому предстоит работать с web-сервисами таких организаций, я все-же рекомендую изучить принцип работы протокола SOAP. При этом Вам не будет необходимости создавать полноценный канонический SOAP-клиент – с SOAP-сервером можно работать как с обычным web-сервисом, отправляя POST-запросы с телом в формате XML и получая ответы также в формате XML. Главное соблюдать регламентированные в описании протокола имена xmlNamespace’ов и, если этого требует конкретный сервис, отправлять в специальных http-заголовках имя вызываемого метода и прочую необходимую информацию.

В заключении хочу дать несколько общих рекомендаций:

  1. ведите всю проектную документацию, не откладывайте «на потом»;
  2. комментируйте весь код своего проекта, даже если этот код предельно очевиден;
  3. используйте метки //TODO: с комментариями внутри своего кода, когда хотите вернуться к какому-либо месту в коде позже для выполнения доработок;
  4. если выполняется разработка коммерческого проекта, который будет разворачиваться на серверах заказчика, рекомендую к прочтению мою статью [2], где я предлагаю методы защиты Вашего продукта от изменений и кражи;
  5. для эффективного управления проектами используйте Scrum или подобные ему методологии;
  6. не пренебрегайте тестированием своего проекта – наймите в свой штат специалиста по контролю качества и тестированию программного обеспечения.

 

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

  1. Гипермедиа / [Электронный ресурс]. - Режим доступа: URL: https://ru.wikipedia.org/wiki/Гипермедиа (дата обращения: 10.09.2021).
  2. Плетнев А.В. Защита проприетарного программного продукта от несанкционированных изменений // Universum: технические науки: электрон. научн. журн. 2021. 9(90). / [Электронный ресурс]. - Режим доступа: URL: https://7universum.com/ru/tech/archive/item/12268 (дата обращения: 27.09.2021).
  3. Чиннатамби К. Изучаем React, 2-е издание, Издательство «Бомбора», 2019.
  4. Клиент – сервер / [Электронный ресурс]. - Режим доступа: URL: https://ru.wikipedia.org/wiki/Клиент_—_сервер (дата обращения: 02.09.2021).
  5. Международная космическая станция NASA перешла с Windows на Debian Linux / [Электронный ресурс]. - Режим доступа: URL: https://1-veda.info/blog/3461/nasa-linux-debian-windows-космическая-станция (дата обращения: 05.09.2021).
  6. Адельштайн Том, Любанович Билл. Системное администрирование в LINUX. – М.: ИД «Питер», 2010.
  7. Ньюмен Сэм. Создание микросервисов. – СПб.: ИД «Питер», 2016.
  8. Алан А. А. Донаван, Брайан У. Керниган, Язык программирования Go, ИД «Вильямс», 2016.
  9. Companies currently using Go throughout the world / [Электронный ресурс]. - Режим доступа: URL: https://github.com/golang/go/wiki/GoUsers (дата обращения: 20.09.2021).
  10. Docker / [Электронный ресурс]. - Режим доступа: URL: https://ru.wikipedia.org/wiki/Docker (дата обращения: 20.09.2021).
  11. gRPC / [Электронный ресурс]. - Режим доступа: URL: https://ru.wikipedia.org/wiki/GRPC (дата обращения: 11.09.2021).
  12. Sebastian Kuzminsky. Linux Out of the Real World. / [Электронный ресурс]. - Режим доступа: URL: https://www.linuxjournal.com/article/2186 (дата обращения: 05.09.2021).
  13. Брэдшоу Ш., Брэзил Й., Ходоров К. MONGO DB. ПОЛНОЕ РУКОВОДСТВО. – М.: ДМК Пресс, 2020.
  14. Шениг Ганс-Юрген. PostgreSQL 11. Мастерство разработки. – М.: ДМК Пресс, 2019.
  15. Protocol Buffers / [Электронный ресурс]. - Режим доступа: URL: https://ru.wikipedia.org/wiki/Protocol_Buffers (дата обращения: 11.09.2021).
  16. React Native / [Электронный ресурс]. - Режим доступа: URL: https://ru.wikipedia.org/wiki/React_Native (дата обращения: 20.09.2021).
  17. REST / [Электронный ресурс]. - Режим доступа: URL: https://ru.wikipedia.org/wiki/REST (дата обращения: 10.09.2021).
  18. SOAP / [Электронный ресурс]. - Режим доступа: URL: https://ru.wikipedia.org/wiki/SOAP (дата обращения: 14.09.2021).
  19. Сегуин Карл. The Little Redis Book (Маленькая книга о Redis) / [Электронный ресурс]. - Режим доступа: URL: https://thesunwave.gitbooks.io/redis/ (дата обращения: 12.09.2021).
  20. Бенджамин Листоун, Эрик Хенчетт. Vue.js в действии. – СПб.: ИД «Питер», 2019.
  21. Who's using Debian? / [Электронный ресурс]. - Режим доступа: URL: https://www.debian.org/users/ (дата обращения: 04.09.2021).

Подписка на рассылку