Tech Stack Advisor: выбор стека

Требования продукта

Веб-интерфейс (frontend)

Готовый HTML для поиска и превью; Сложный интерфейс: состояние, формы, роли

Серверная часть и API (backend)

Один язык и общие типы с клиентами; Админка и редакторы справочников; Рядом с Python-кодом (данные, ML); Быстрый старт небольшого API

Мобильное приложение: один код на две платформы

Публикация в App Store и Google Play; Доступ к API устройства; Работа без сети; Веб-версия из того же кода; Системные элементы интерфейса; Одинаковый фирменный интерфейс

Мобильное приложение: нативная разработка

Новые и глубокие API ОС; Интерфейс по правилам платформы; Одинаковый фирменный интерфейс

Основная база данных

Связи, отчёты, JOIN, транзакции; Гибкая структура записей

Опыт команды

Веб-интерфейс (frontend)

Опыт команды

Серверная часть и API (backend)

Опыт команды

Мобильное приложение: один код на две платформы

Опыт команды

Мобильное приложение: нативная разработка

Опыт команды

Основная база данных

Опыт команды

Стоимость поддержки

Веб-интерфейс (frontend)

Простота хостинга; Готовые соглашения: маршруты, данные, рендеринг

Серверная часть и API (backend)

Структура для долгоживущей системы; Готовые инструменты эксплуатации; Сроки поддержки версий

Мобильное приложение: один код на две платформы

Выпуск обновлений; Обязательные обновления под требования магазинов

Мобильное приложение: нативная разработка

Общий код Android и iOS; Долгая поддержка: кодовые базы и зависимости

Основная база данных

Без отдельного сервера БД; Обновление мажорных версий

Производительность

Веб-интерфейс (frontend)

Первая загрузка на слабых устройствах

Серверная часть и API (backend)

Тяжёлые вычисления в процессе API

Мобильное приложение: один код на две платформы

Плотная анимация и длинные списки

Мобильное приложение: нативная разработка

Производительность

Основная база данных

Распределение записи по серверам

Безопасность

Веб-интерфейс (frontend)

Поверхность атаки и обновления безопасности

Серверная часть и API (backend)

Встроенные защиты

Мобильное приложение: один код на две платформы

Хранение секретов на устройстве

Мобильное приложение: нативная разработка

Хранение секретов на устройстве

Основная база данных

Права доступа внутри базы

Опыт команды (опыт команды)

Статический сайт

по опыту

React + Next.js

по опыту

React SPA

по опыту

Vue + Nuxt

по опыту

Вес из ответов

3: Сроки сжатые: знакомый стек ускоряет первый релиз; 2: Обычные сроки; 1: Есть запас времени на освоение

Готовый HTML для поиска и превью (требования продукта)

Статический сайт

2 — Страницы — готовые HTML-файлы

React + Next.js

2 — SSR и SSG отдают готовый HTML

React SPA

0 — Содержимое появляется после выполнения JavaScript в браузере

Vue + Nuxt

2 — SSR и SSG отдают готовый HTML

Вес из ответов

3: Поиск — основной канал; 1: Поиск важен для части страниц; 0: Поиск не важен

Сложный интерфейс: состояние, формы, роли (требования продукта)

Статический сайт

0 — Фреймворка приложения нет: состояние и логику пришлось бы собирать вручную

React + Next.js

2 — Компоненты React, маршруты и серверная часть в одном проекте

React SPA

2 — Компоненты React; маршрутизация и данные — отдельными библиотеками

Vue + Nuxt

2 — Компоненты Vue, маршруты и серверная часть в одном проекте

Вес из ответов

3: Интерфейс сложный; 2: Интерфейс средней сложности; 0: Интерфейс простой

Простота хостинга (стоимость поддержки)

Статический сайт

2 — Любой статический хостинг или CDN

React + Next.js

1 — Server Actions, cookies, ISR требуют Node.js-сервера; статический экспорт их отключает

React SPA

2 — Сборка — статические файлы

Vue + Nuxt

1 — SSR требует Node.js-сервера; статическая генерация возможна

Вес из ответов

3: Доступен только статический хостинг; 1: Хостинг без особых ограничений

Готовые соглашения: маршруты, данные, рендеринг (стоимость поддержки)

Статический сайт

1 — Для контентного сайта соглашений генератора достаточно

React + Next.js

2 — Маршруты-папки, серверные и клиентские компоненты

React SPA

0 — Маршрутизацию и загрузку данных выбираете сами; React рекомендует для новых приложений фреймворк

Vue + Nuxt

2 — Файловая маршрутизация и серверный рендеринг

Вес из ответов

3: Продукт будут поддерживать годы, возможно другая команда; 2: Срок поддержки не определён; 1: Короткий горизонт

Первая загрузка на слабых устройствах (производительность)

Статический сайт

2 — Готовый HTML и минимум JavaScript

React + Next.js

1 — HTML приходит с сервера; интерактивность — после загрузки JavaScript и гидратации

React SPA

0 — Ничего не видно, пока не загрузится и не выполнится JavaScript-бандл

Vue + Nuxt

1 — HTML приходит с сервера; интерактивность — после загрузки JavaScript и гидратации

Вес из ответов

2: Тяжёлые экраны и слабые устройства: важен объём JavaScript при загрузке; 1: Требования к производительности не определены; 0: Обычные требования

Поверхность атаки и обновления безопасности (безопасность)

Статический сайт

2 — Нет серверного кода: защищать нужно хостинг и процесс сборки

React + Next.js

1 — Серверный рантайм: уязвимости фреймворка закрываются обновлениями, их нужно ставить быстро

React SPA

2 — Статические файлы; проверка прав — на стороне backend

Vue + Nuxt

1 — Серверный рантайм: уязвимости фреймворка закрываются обновлениями, их нужно ставить быстро

Вес из ответов

3: Платежи, медицина или данные с требованиями регулятора; 2: Персональные данные; 1: Публичные данные: базовая гигиена безопасности

Опыт команды (опыт команды)

Node.js (NestJS или Express), TypeScript

по опыту

Spring Boot

по опыту

Python + FastAPI

по опыту

Python + Django

по опыту

Вес из ответов

3: Сроки сжатые: знакомый стек ускоряет первый релиз; 2: Обычные сроки; 1: Есть запас времени на освоение

Один язык и общие типы с клиентами (требования продукта)

Node.js (NestJS или Express), TypeScript

2 — TypeScript на сервере и клиентах

Spring Boot

0 — Другой язык: типы описываются контрактом (например, OpenAPI)

Python + FastAPI

0 — Другой язык: типы — через OpenAPI-схему

Python + Django

0 — Другой язык: типы описываются контрактом

Вес из ответов

2: Клиенты на TypeScript, общие типы важны; 0: Общие типы не важны; 0: API вызывают только сервисы

Структура для долгоживущей системы (стоимость поддержки)

Node.js (NestJS или Express), TypeScript

1 — NestJS задаёт архитектуру (модули, DI); в Express структуру держит команда

Spring Boot

2 — Слои, стартеры, автоконфигурация

Python + FastAPI

1 — Маршруты, валидация и Depends; остальное собираете сами

Python + Django

2 — ORM, миграции, аутентификация и соглашения в комплекте

Вес из ответов

3: Продукт будут поддерживать годы, возможно другая команда; 2: Срок поддержки не определён; 1: Короткий горизонт

Админка и редакторы справочников (требования продукта)

Node.js (NestJS или Express), TypeScript

1 — Подключается библиотеками или пишется

Spring Boot

1 — Подключается библиотеками или пишется

Python + FastAPI

1 — Подключается библиотеками или пишется

Python + Django

2 — Автоматическая админка по моделям — для внутренних пользователей

Вес из ответов

2: Нужна админка для сотрудников; 0: Админка не нужна

Рядом с Python-кодом (данные, ML) (требования продукта)

Node.js (NestJS или Express), TypeScript

0 — Python-код — отдельным сервисом

Spring Boot

0 — Python-код — отдельным сервисом

Python + FastAPI

2 — Тот же язык и процесс

Python + Django

2 — Тот же язык и процесс

Вес из ответов

2: Python в том же процессе желателен; 0: Не влияет или учтено как жёсткое ограничение

Быстрый старт небольшого API (требования продукта)

Node.js (NestJS или Express), TypeScript

2 — Express — минимальный каркас; NestJS — больше понятий

Spring Boot

1 — Для маленького сервиса — больше понятий и конфигурации на старте

Python + FastAPI

2 — Маршрут, модель Pydantic — и документация API готова

Python + Django

1 — Много соглашений с первого дня

Вес из ответов

2: Важен быстрый первый релиз; 1: Обычные сроки; 0: Сроки не давят

Готовые инструменты эксплуатации (стоимость поддержки)

Node.js (NestJS или Express), TypeScript

1 — Метрики и health checks подключаются библиотеками

Spring Boot

2 — Actuator: health, метрики, аудит через HTTP или JMX

Python + FastAPI

1 — Метрики и health checks подключаются библиотеками

Python + Django

1 — Метрики и health checks подключаются библиотеками

Вес из ответов

2: Долгая эксплуатация; 2: API используют другие сервисы — важны наблюдаемость и health checks; 1: Обычная эксплуатация

Тяжёлые вычисления в процессе API (производительность)

Node.js (NestJS или Express), TypeScript

0 — Руководство Node.js: тяжёлые вычисления выносить из Event Loop; при большом их объёме оценить, подходит ли Node.js

Spring Boot

2 — Многопоточность JVM

Python + FastAPI

1 — GIL в CPython: Python-байткод исполняет один поток; вычисления — процессами или библиотеками, отпускающими GIL

Python + Django

1 — GIL в CPython: Python-байткод исполняет один поток; вычисления — процессами или библиотеками, отпускающими GIL

Вес из ответов

3: Тяжёлые вычисления в запросах; 0: Обычная нагрузка

Сроки поддержки версий (стоимость поддержки)

Node.js (NestJS или Express), TypeScript

1 — Ветка Node.js LTS — около 30 месяцев; у NestJS и Express свои циклы выпуска — следить за обоими

Spring Boot

1 — Бесплатная поддержка минорной версии Spring Boot — около 13 месяцев: обновляться регулярно

Python + FastAPI

1 — Версии 0.x: документация FastAPI предупреждает о несовместимых изменениях в минорных версиях — фиксируйте версии

Python + Django

2 — LTS-релизы с исправлениями безопасности не меньше трёх лет

Вес из ответов

2: Продукт будут поддерживать годы, возможно другая команда; 1: Срок поддержки не определён; 0: Короткий горизонт

Встроенные защиты (безопасность)

Node.js (NestJS или Express), TypeScript

1 — В Express защиты — сторонними пакетами (Helmet, защита входа от перебора); в NestJS заголовки безопасности и ограничение частоты есть в официальных модулях, остальное — пакетами

Spring Boot

2 — Spring Security: аутентификация, авторизация, CSRF и заголовки безопасности

Python + FastAPI

1 — Инструменты OAuth2 и ключей API в комплекте; остальные меры — сами

Python + Django

2 — CSRF, экранирование в шаблонах, защита от SQL-инъекций через ORM, clickjacking — из коробки

Вес из ответов

3: Платежи, медицина или данные с требованиями регулятора; 2: Персональные данные; 1: Публичные данные: базовая гигиена безопасности

Опыт команды (опыт команды)

PWA

по опыту

React Native + Expo

по опыту

Flutter

по опыту

Вес из ответов

3: Сроки сжатые: знакомый стек ускоряет первый релиз; 2: Обычные сроки; 1: Есть запас времени на освоение

Публикация в App Store и Google Play (требования продукта)

PWA

1 — Через упаковку (например, PWABuilder); правила у каждого магазина свои

React Native + Expo

2 — Обычная сборка для магазинов

Flutter

2 — Обычная сборка для магазинов

Вес из ответов

3: Магазины обязательны; 1: Нужность магазинов не определена; 0: Магазины не нужны

Доступ к API устройства (требования продукта)

PWA

1 — В пределах API браузера; поддержка различается по платформам

React Native + Expo

2 — Модули Expo и сообщества или свой нативный модуль

Flutter

2 — Плагины или свой код через platform channels

Вес из ответов

3: Нужны API за пределами браузера; 2: Нужны стандартные API устройства; 0: API устройства почти не нужны

Работа без сети (требования продукта)

PWA

1 — Service Worker и кэш; фоновая синхронизация (Background Sync) есть не во всех браузерах

React Native + Expo

2 — Локальная база на устройстве и своя синхронизация

Flutter

2 — Локальная база на устройстве и своя синхронизация

Вес из ответов

3: Offline-first; 1: Нужно показывать загруженное без сети; 0: Офлайн не нужен

Веб-версия из того же кода (требования продукта)

PWA

2 — Это и есть веб

React Native + Expo

1 — React Native for Web в Expo

Flutter

1 — Flutter web

Вес из ответов

2: Нужен веб из того же кода; 0: Веб не нужен

Системные элементы интерфейса (требования продукта)

PWA

1 — Веб-интерфейс

React Native + Expo

2 — Компоненты превращаются в нативные представления Android и iOS

Flutter

1 — Собственные виджеты, повторяющие системные

Вес из ответов

2: Интерфейс строго по правилам платформы; 0: Не требуется

Одинаковый фирменный интерфейс (требования продукта)

PWA

1 — Веб-вёрстка, зависит от браузера

React Native + Expo

1 — Возможно, но элементы остаются системными

Flutter

2 — Рисует интерфейс сам: выглядит одинаково на всех версиях ОС

Вес из ответов

3: Нужен одинаковый фирменный интерфейс, и он сложный; 2: Нужен одинаковый фирменный интерфейс; 0: Не требуется

Выпуск обновлений (стоимость поддержки)

PWA

2 — Обновление на сервере, без проверки магазина

React Native + Expo

1 — Новые версии — через магазины

Flutter

1 — Новые версии — через магазины

Вес из ответов

2: Важна скорость выпуска; 1: Обычный цикл выпуска

Обязательные обновления под требования магазинов (стоимость поддержки)

PWA

2 — Без сборок для магазинов требования к целевой версии SDK не действуют (после упаковки в магазин — действуют)

React Native + Expo

1 — Магазины регулярно поднимают требования к целевому SDK: обновлять React Native и Expo и пересобирать

Flutter

1 — Магазины регулярно поднимают требования к целевому SDK: обновлять Flutter и пересобирать

Вес из ответов

2: Продукт будут поддерживать годы, возможно другая команда; 1: Срок поддержки не определён; 0: Короткий горизонт

Плотная анимация и длинные списки (производительность)

PWA

1 — В пределах браузерного движка: плавность зависит от браузера и устройства

React Native + Expo

2 — Нативные представления; списки и анимации — специальными компонентами

Flutter

2 — Код компилируется заранее (AOT), интерфейс рисует собственный движок

Вес из ответов

2: Плотная анимация, длинные списки, слабые устройства; 1: Требования к производительности не определены; 0: Обычные требования

Хранение секретов на устройстве (безопасность)

PWA

1 — Только хранилища браузера; системные Keychain и Keystore недоступны

React Native + Expo

2 — Keychain и Keystore через expo-secure-store

Flutter

2 — Keychain и Keystore через плагины

Вес из ответов

3: Платежи, медицина или данные с требованиями регулятора; 2: Персональные данные; 1: Публичные данные: базовая гигиена безопасности

Опыт команды (опыт команды)

Два нативных приложения

по опыту

Kotlin Multiplatform

по опыту

Compose Multiplatform

по опыту

Вес из ответов

3: Сроки сжатые: знакомый стек ускоряет первый релиз; 2: Обычные сроки; 1: Есть запас времени на освоение

Новые и глубокие API ОС (требования продукта)

Два нативных приложения

2 — Сразу после выхода SDK платформы

Kotlin Multiplatform

2 — Интерфейс и платформенный код — нативные

Compose Multiplatform

1 — Нативные элементы встраиваются через interop

Вес из ответов

3: Нужны глубокие API и новые возможности ОС; 1: Стандартные API; 0: Особых API нет

Интерфейс по правилам платформы (требования продукта)

Два нативных приложения

2 — Compose и SwiftUI — системные фреймворки

Kotlin Multiplatform

2 — Интерфейс нативный на каждой платформе

Compose Multiplatform

1 — Общий интерфейс на Compose; SwiftUI и UIKit — через interop

Вес из ответов

2: Интерфейс строго по правилам платформы; 0: Не требуется

Общий код Android и iOS (стоимость поддержки)

Два нативных приложения

0 — Каждую функцию делают дважды

Kotlin Multiplatform

1 — Общая бизнес-логика

Compose Multiplatform

2 — Общие логика и интерфейс

Вес из ответов

3: Сжатые сроки: дублирование дорого; 2: Обычные сроки; 1: Есть запас

Одинаковый фирменный интерфейс (требования продукта)

Два нативных приложения

1 — Два интерфейса нужно держать одинаковыми вручную

Kotlin Multiplatform

1 — Два интерфейса нужно держать одинаковыми вручную

Compose Multiplatform

2 — Один интерфейс на обе платформы

Вес из ответов

2: Нужен одинаковый фирменный интерфейс; 0: Не требуется

Долгая поддержка: кодовые базы и зависимости (стоимость поддержки)

Два нативных приложения

1 — Две кодовые базы, зато только собственные инструменты Apple и Google

Kotlin Multiplatform

1 — Общая логика в одной базе; добавляется зависимость от инструментов Kotlin Multiplatform

Compose Multiplatform

1 — Одна кодовая база; интерфейс iOS зависит от Compose Multiplatform

Вес из ответов

2: Продукт будут поддерживать годы, возможно другая команда; 1: Срок поддержки не определён; 0: Короткий горизонт

Производительность (производительность)

Два нативных приложения

2 — Нативный код; различий без замеров на своём сценарии не утверждаем

Kotlin Multiplatform

2 — Нативный код; различий без замеров на своём сценарии не утверждаем

Compose Multiplatform

2 — Нативный код; различий без замеров на своём сценарии не утверждаем

Вес из ответов

2: Плотная анимация, длинные списки, слабые устройства; 1: Требования к производительности не определены; 0: Обычные требования

Хранение секретов на устройстве (безопасность)

Два нативных приложения

2 — Прямой доступ к Keychain и Keystore

Kotlin Multiplatform

2 — Keychain и Keystore через платформенный код

Compose Multiplatform

2 — Keychain и Keystore через платформенный код

Вес из ответов

3: Платежи, медицина или данные с требованиями регулятора; 2: Персональные данные; 1: Публичные данные: базовая гигиена безопасности

Опыт команды (опыт команды)

PostgreSQL

по опыту

MySQL

по опыту

MongoDB

по опыту

SQLite

по опыту

Вес из ответов

3: Сроки сжатые: знакомый стек ускоряет первый релиз; 2: Обычные сроки; 1: Есть запас времени на освоение

Связи, отчёты, JOIN, транзакции (требования продукта)

PostgreSQL

2 — Реляционная модель, транзакционные миграции

MySQL

2 — Реляционная модель

MongoDB

1 — Связи — встраиванием или $lookup; многодокументные транзакции есть, но модель строится вокруг документа

SQLite

2 — Реляционная модель

Вес из ответов

3: Много связей и отчётов; 2: В основном связи; 0: Связей мало

Гибкая структура записей (требования продукта)

PostgreSQL

2 — jsonb с индексами GIN

MySQL

1 — Тип JSON; индексы — через генерируемые столбцы

MongoDB

2 — Документная модель

SQLite

1 — JSON-функции

Вес из ответов

3: Данные — самостоятельные документы; 2: Часть полей гибкая; 0: Структура строгая

Распределение записи по серверам (производительность)

PostgreSQL

1 — Партиционирование встроено; распределение по серверам — внешними средствами

MySQL

1 — Кластерные решения — отдельная архитектура

MongoDB

2 — Встроенный шардинг

SQLite

0 — Один файл, один пишущий процесс

Вес из ответов

3: Ожидается поток записи больше одного сервера; 1: Объём не определён; 0: Хватит одного сервера

Без отдельного сервера БД (стоимость поддержки)

PostgreSQL

1 — Отдельный сервер или управляемый сервис

MySQL

1 — Отдельный сервер или управляемый сервис; часто уже есть у хостинга

MongoDB

1 — Отдельный сервер или управляемый сервис

SQLite

2 — Файл рядом с приложением

Вес из ответов

2: Сжатые сроки и один сервер приложения; 0: Не влияет

Обновление мажорных версий (стоимость поддержки)

PostgreSQL

1 — Мажорное обновление — pg_upgrade или выгрузка и загрузка; планируется заранее

MySQL

1 — Мажорное обновление планируется заранее по описанным путям обновления

MongoDB

1 — Мажорные версии обновляются последовательно, одна за другой

SQLite

2 — Формат файла стабилен и обратно совместим; проект обещает поддержку до 2050 года

Вес из ответов

2: Продукт будут поддерживать годы, возможно другая команда; 1: Срок поддержки не определён; 0: Короткий горизонт

Права доступа внутри базы (безопасность)

PostgreSQL

2 — Роли, привилегии и политики на уровне строк (row-level security)

MySQL

2 — Пользователи и привилегии вплоть до столбцов

MongoDB

2 — Ролевая модель доступа (RBAC)

SQLite

1 — Пользователей и прав нет: доступ определяют права на файл и код приложения

Вес из ответов

3: Платежи, медицина или данные с требованиями регулятора; 2: Персональные данные; 1: Публичные данные: базовая гигиена безопасности