Технологический стек RB Tech

Как мы выбираем технологии для разработки, поддержки и развития цифровых систем

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

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

Как выбираем технологии

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

Мы предпочитаем инструменты, с которыми можем строить устойчивые процессы.

Контекст — главный критерий

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

Гибкость и сценарный подход

Вместо универсальных рецептов — набор решений под разные условия.

Стек RB Tech

Серверная часть

  • Node.js, TypeScript (Nest.js, Express) — лёгкие и масштабируемые серверные приложения.
  • Python (Flask, Django, FastAPI) — API, интеграции и решения с элементами искусственного интеллекта.
  • ORM: TypeORM, Prisma — для типизированного доступа к данным.
  • BullMQ — фоновые очереди и управление асинхронными задачами.
  • Swagger / OpenAPI — описание, согласование и тестирование API.

Пользовательские интерфейсы

  • React, Next.js — сложные интерфейсы с серверным рендерингом.
  • Electron — кроссплатформенные десктоп-приложения.
  • Tailwind, Material UI, Bootstrap — UI-фреймворки.
  • Styled Components, Emotion, CSS-in-JS — стилизация компонентов.
  • Vite — быстрая сборка и дев-среда для прикладных интерфейсов.
  • Jest — модульное тестирование.
  • React Admin, Strapi — административные интерфейсы и безголовая CMS.
  • Apollo GraphQL, React Query — клиентские интеграции с API по GraphQL и REST.
  • Webpack — сборка модулей и оптимизация.

Мобильная разработка

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

  • React Native, Flutter — кроссплатформенность и скорость разработки.
  • Kotlin, Swift — нативная производительность.
  • Kotlin Multiplatform — переиспользование бизнес-логики между мобильными платформами.
  • Android SDK — прикладная разработка и интеграция с системными возможностями платформы.
  • Jetpack Compose — современная декларативная разработка интерфейсов Android-приложений.
  • Android, AOSP — платформенная основа для разработки мобильной ОС и системных компонентов.
  • AndroidX / Jetpack — прикладные библиотеки и инфраструктура Android-приложений.
  • Material Design / Material Components — проектирование и разработка пользовательских интерфейсов Android-приложений.
  • Soong, Android.bp, Android.mk — сборка и конфигурация Android-платформы.

Системная и платформенная разработка

  • C/C++ — низкоуровневая и платформенная разработка системных компонентов.
  • Linux / POSIX — системное окружение и базовые интерфейсы платформенного слоя.

Искусственный интеллект и интеллектуальная обработка данных

  • Apache Airflow — оркестрация задач и пайплайнов через направленные графы задач.
  • LLM (Large Language Models) — генерация, интерпретация и обогащение текстов.
  • RAG (Retrieval-Augmented Generation) — генерация с доступом к внешним данным.
  • KubeAI — оркестрация и автоматизация рабочих процессов с участием LLM.
  • Tesseract OCR — извлечение текста из изображений и PDF.

DevOps и инфраструктура

  • Kubernetes, Docker — изоляция и управление окружениями.
  • Nginx, Traefik — маршрутизация и балансировка трафика.
  • GitLab CI/CD, ArgoCD — автоматизация поставки и управления релизами.
  • GitOps — управление изменениями инфраструктуры и приложений через Git как источник истины.
  • Terraform, Helm — управление инфраструктурой как кодом.
  • Proxmox, K3s — гибкость в виртуализации и кластеризации.
  • Let's Encrypt — автоматическая выдача TLS-сертификатов.

Хранение и данные

  • PostgreSQL, Redis — реляционные базы и хранилища типа ключ-значение.
  • MongoDB — документо-ориентированное хранилище.
  • ClickHouse — высокопроизводительное аналитическое хранилище для обработки больших объёмов данных.
  • MinIO, S3 — объектное хранилище.
  • Elasticsearch, OpenSearch — полнотекстовый поиск и аналитика.
  • Apache Superset, Cube.js — построение интерактивных дашбордов и визуализация данных для аналитики.

Мониторинг и безопасность

  • Prometheus, Grafana — метрики и визуализация.
  • Sentry, Kibana — мониторинг ошибок и логов.
  • Keycloak, Ory Keto — централизованное управление доступом.
  • JWT, OAuth2, OpenID Connect (OIDC) — авторизация.
  • MQTT — протокол обмена сообщениями для интернета вещей и лёгкой связи в реальном времени.

Интеграции и API

  • REST API, GraphQL, gRPC — взаимодействие между сервисами.
  • Swagger, OpenAPI — спецификации и тестирование.
  • Kafka — очереди сообщений.
  • Socket.IO, WebSockets — обмен данными в реальном времени.

Процессы и автоматизация

  • BPMN, DMN, Camunda, Zeebe — моделирование и исполнение бизнес-процессов.
  • PlantUML (UML, ERD / ER, DFD, IDEF) — моделирование и визуализация процессов, данных и архитектуры.
  • ArchiMate — моделирование корпоративной архитектуры на уровнях бизнеса, приложений и технологий.
  • Bull, Celery — фоновые задачи.
  • Draw.io, Form.io — визуализация и формы.

Что подготовить

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

Нагрузка и сценарии

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

Данные и интеграции

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

Безопасность и доступы

Какие роли, протоколы авторизации, персональные данные, журналы и ограничения нужно учитывать заранее.

Команда и сопровождение

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

Сроки и бюджет

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

Эксплуатация

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

Как проверить стек

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

Не лучший вообще, а уместный в контексте

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

Стек должен переживать не только запуск, но и развитие

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

Роли стека в системе

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

Пользовательский контур

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

Серверный и интеграционный контур

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

Фоновые задачи, телеметрия и обработка событий

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

Аналитика и наблюдаемость

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

Развертывание и конфигурация

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

Когда пересматривать стек

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

Типовые признаки, что стек требует отдельного разбора:

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

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

Что даёт бизнесу

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

Что дальше

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

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

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

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

Создано
16.05.2026
Обновлено
12.07.2026