Привет, Хабр! Меня зовут Дмитрий Адмакин, руководитель отдела архитектурных решений и перспективной разработки одного из бизнес-центров в компании «БАРС Груп». Сегодня я расскажу о том, как мы создавали современную систему мониторинга по исполнению государственных программ, и что из этого вышло.

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

Было проведено более 100 собеседований. Старались отойти от  традиционных методов подбора персонала. Нам хотелось убедиться, что кандидаты обладают именно практическими навыками. Например, предлагали человеку задать себе вопросы, благодаря этому становилось понятно, как кандидат оценивает себя, и в каких темах он разбирается. Говорили про C#, ReactJS, SQL и noSQL, брокеров сообщений, контейнеризацию и т.д. Интересный опыт.

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

1. Rest vs gRPC vs GraphQL

2. C#. Сериализация, десериализация
   Потоки

3. C# 

   int i = 1; 
   object o = i; 
   ++i;
   Console.WriteLine(i);
   Console.WriteLine(o);
   Console.WriteLine((short)o);

4. React. debounce, throttle.

5. React. package-lock.json для чего используется, что это?

6. JS. Callback, промисы, async/await.

7. SQL. truncate vs delete vs drop.

8. SQL. count(*) vs count(name) – могут ли отличаться? И если могут, то в каких случаях?

9. Redis. Что это? Почему работает быстро? Как сделать автоудаление данных?

После «мучительных» поисков (2-3 месяца) наша команда пополнилась новыми сотрудниками, в которую вошли:

• TechLead

• FullStack-разработчики 

• Frontend-разработчики

• Backend-разработчики

• Аутсорс-разработчики

А теперь о самой команде и задачах, стоящих перед ними: 

• Backend-разработчики писали много шарпового кода, взаимодействовали через EF с базой данных, реализовывали сервисы межсетевого взаимодействия (СМЭВ). 

• Frontend-разработчики работали над созданием компонентов — фантастических и максимально переиспользуемых.

• FullStack-разработчики помогали направить и подружить между собой frontend и backend.

• TechLead доверили не только управление командой в части технологий, но и CI/CD совместно с DevOps’ом.

• Аутсорс-разработчики занимались реализацией UI-kitа. Заказчик привык к компонентам, написанным и стилизованным на другом фреймворке, и нам пришлось провести большую работу, чтобы переписать эти компоненты на ReactJS. 

Кроме того, совместно с аналитиками был изменен подход к созданию и описанию задач. Теперь в задачах необходимо разделять backend и frontend, а не ставить их в общем виде. 

Немного о технологиях

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

В работе были использованы следующие языки программирования и технологии: 

• Front — React JS. Почему React? Лицензия MIT, количество специалистов на рынке, огромное число расширений для фреймворка.

• Front — язык разработки — TypeScript. Видели мемасики про JS? Будь TypeScript раньше, возможно этих мемасиков не было бы.

• Front — стилизация компонентов — Ant Design. Огромная библиотека готовых компонентов, иногда не нужно «изобретать велосипед», когда можно использовать готовое.

• Server side rendering — next.js. Тут я думаю, что вариантов особо нет, юзаем SSR.

• Взаимодействие Back и Front — GraphQL. GraphQL позволяет снижать нагрузку на БД, «гонять» меньше данных по сети, легче организовывать единую точка входа. Что еще нужно?

• Back — .NET 5 (C#). Вы спросите, почему не .NET 6? Уже он. Перешли.

• Microservices — Go. Вы видели сколько ресурсов в ждущем режиме занимают приложения на Go? Модно, быстро.

• БД — PostgreSQL. Один из стандартов для хранения данных. Как приятный бонус, существенная экономия денег.

• ORM — EntityFramework Core, Dapper. Если нам нужен контроль над запросами и скорость, то используем Dapper. Для всего остального — EF.

• NoSQL хранилище — ElasticSearch. Мы храним не только логи в ES, но и полнотекстовый поиск построен также на ES. Один из наших микросервисов «закидывает» в ES данные из БД, по которым будет создан полнотекст. 

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

• Брокер сообщений — Kafka. Знаю, знаю! Kafka - не классический брокер сообщений, но большинство компаний используют его именно как брокер. Мы не стали исключением. 

• Контейнеризация — Docker, Kubernetes, Portainer. Стандарт в части контейнеризации. Расскажите, был ли опыт у вас в высоконагруженных системах? 

• Хранилище файлов — Ceph (Amazon s3). Хранить файлы просто на сервере в файловой системе — прошлый век. Поэтому стали использовать CEPH, поднятый на инфраструктуре заказчика.

• Для сборки и выкладки — Werf. Про Werf писали на «Хабр». Кстати, нам понравилось. Также мы попробовали на тестовых проектах — «зашло». Решили идти на прод.

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

Если кратко, у нас есть некий монолит, который взаимодействует с другими системами и микросервисами через GraphQL, REST, gRPC или брокеры сообщений. Все это поднято на Kubernetes.

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

Уверен, что у вас появился вопрос, почему мы выбрали данный стек?

• Популярность.

• Быстродействие.

• Стабильность и поддержка.

• Лицензионная политика, OpenSource.

• Взаимодействие со всеми продуктами. 

• Опыт внедрения в других коммерческих приложениях.

• Максимальная автоматизация процессов.

В качестве фреймворка для Frontend был выбран React.

Итог

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

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

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

Было ли нам сложно? Сложности были на начале становления проекта. Мы долго решали на чем писать front — собирались, спорили, обсуждали. Сроки были максимально сжатые, а использовать что-то неизведанное было страшно. Но я понимал, что мы найдем отличных специалистов. Спойлер! У нас получилось. Теперь мы знаем, что создать достаточно большой проект с нуля до выкладки на промышленный сервер можно за 3 месяца. 

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

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