Technology Radar

Основной язык frontend-разработки. Используем строгую типизацию и учитываем изменения TypeScript 6 перед переходом на будущий нативный компилятор.

Основная UI-библиотека. Текущие приложения используют React 19.2 с современными API рендеринга и форм.

Основной фреймворк для публичных сайтов и SEO-ориентированных продуктов. Используем App Router, Server Components и Turbopack.

Основной build tool для SPA и внутренних приложений. Vite 8 перешёл на единый bundler Rolldown; миграции проверяем через полный набор тестов.

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

Используем для мобильных продуктов, где нужен общий TypeScript/React-стек и нативный интерфейс iOS и Android.

Маршрутизация SPA и рабочих кабинетов с типизированными маршрутами и управляемым состоянием URL.

Стандартный слой серверного состояния во frontend: кеширование, повторные запросы, mutations и синхронизация интерфейса с API.

Используем для системного UI, адаптивных интерфейсов и быстрой работы с дизайн-токенами.

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

Применяем точечно для сложных SPA, когда особенно важны типобезопасные маршруты и search params.

Язык Garmin Connect IQ. Используем для циферблатов и приложений с жёсткими ограничениями памяти, экрана и энергопотребления.

Следим за нативным компилятором TypeScript 7, но не используем preview-сборки в production.

Прогрессивный фреймворк для построения UI. Оцениваем для некоторых проектов.

Оцениваем точечно для enterprise-контекста. Для большинства MVP и продуктовых запусков выбираем более быстрые по delivery альтернативы.

Считаем нишевым выбором: скорее для гиковых кейсов. Для крупных коммерческих проектов экосистема и рынок найма пока слабее.

Рассматриваем для Vue-ориентированных команд, но по умолчанию в новых запусках чаще идём через React/Next стек.

Изучаем для отдельных web-продуктов. Пока используем ограниченно, когда есть явный выигрыш по UX и маршрутизации.

Зачем медленный Python и Django, если есть быстрый и надежный Go? Рассматриваем только под специфичные Python-first задачи и интеграции с ML/Data, но не как основной backend-стек.

Не используем для новых проектов: PHP/Laravel-стек не входит в наш целевой production-набор и не соответствует текущей стратегии скорости и поддержки.

Не используем в новых запусках: текущий delivery-процесс и экспертиза команды сфокусированы на TypeScript/Node/Go экосистеме.

Не используем в новых проектах: усложняет поддержку, ухудшает типобезопасность и плохо сочетается с современными React/Next архитектурами.

Не выбираем для новых проектов: React официально прекратил развитие CRA и рекомендует frameworks или современные build tools.

Только поддержка legacy: официальный long-term support завершён.

Используем для кроссплатформенных десктопных и мобильных приложений на веб-технологиях с бэкендом на Rust: легкий бандл и минимальное потребление RAM.

Легковесный сверхбыстрый веб-фреймворк для Edge, Cloudflare Workers, Node.js и Bun с полной типобезопасностью.

Не используем в новых проектах: избыточный бойлерплейт. Zustand и TanStack Query закрывают клиентское и серверное состояние проще и надежнее.

Не используем в новых запусках: уступает нашему стеку TypeScript/Go по строгой типизации, скорости API и эффективности инфраструктуры.

Не рекомендуем для веб-приложений: холстовый рендеринг через CanvasKit/WASM ухудшает SEO, доступность (a11y), выделение текста и размер бандла.

Не выбираем для простых десктопных утилит: потребление 300+ МБ памяти ради веб-обертки не оправдано при наличии легковесного Tauri.

Основная транзакционная база данных: строгая целостность, миграции, JSONB и зрелый инструментарий.

Объектное хранилище для пользовательских файлов, релизов и изображений. Используем S3 API и MinIO-совместимые реализации.

Используем для realtime-сценариев, где polling создаёт лишнюю задержку или нагрузку.

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

Подключаем для кеша, rate limiting и краткоживущего состояния только при подтверждённой необходимости.

Подходит для автоматических проверок и поставки репозиториев GitHub; production-активации оставляем управляемыми для критичных систем.

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

Векторные эмбеддинги и семантический AI-поиск прямо в PostgreSQL без необходимости поднимать и оплачивать отдельные векторные базы данных.

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

Сверхбыстрый нативный linter и formatter на Rust. Оцениваем для ускорения CI и локальной разработки на замену связки ESLint + Prettier.

Не рекомендуем как стартовую инфраструктуру MVP без измеримой потребности: стоимость эксплуатации обычно выше пользы.

Не рекомендуем как основную БД для транзакционных и связанных данных: PostgreSQL с нативным JSONB дает целостность, типизацию и гибкость без проблем с консистентностью.

Не используем ручную настройку production-серверов по SSH: все окружения разворачиваются через воспроизводимый Docker, CI/CD или управляемые PaaS.

Не используем в новых проектах: громоздкие конфигурации и медленная сборка. Стандарт разработки — Vite 8 (Rolldown) и Turbopack.

Платформа для Next.js и frontend-приложений, когда её модель хостинга и стоимость соответствуют продукту.

Используем в production для продуктов, которым подходят управляемые PostgreSQL, Auth, Storage и realtime-возможности.

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

Применяем для измеримых AI-сценариев с контролем стоимости, конфиденциальности, fallback и качества результата.

Подключаем для error tracking и performance monitoring, когда продукту нужен централизованный production-observability.

Оцениваем для узких мобильных и realtime-сценариев; заранее моделируем стоимость и переносимость данных.

Не рекомендуем для новых продуктовых запусков: дорогая поддержка, сложная эволюция архитектуры и высокий vendor lock-in.

Не используем для новых сайтов и продуктовых запусков: высокий vendor lock-in, сложная поддержка и ограниченная гибкость архитектуры.

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

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

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

Не используем No-code (Bubble, Webflow) для кастомных SaaS: жесткий потолок кастомизации, vendor lock-in и неизбежное дорогое переписывание с нуля.

Не пишем кастомную авторизацию и криптографию с нуля на старте MVP: готовые Supabase Auth или провайдеры экономят недели и гарантируют безопасность.

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

Комбинируем unit, integration и browser E2E-тесты пропорционально риску изменения.

Каждый релиз проходит воспроизводимые проверки, сборку и smoke-check; активация production может оставаться ручной и контролируемой.

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

Используем в Next.js для уменьшения клиентского JavaScript и серверного получения данных; границы client/server проектируем явно.

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

Поставляем небольшими проверяемыми изменениями с возможностью отката и коротким циклом обратной связи.

Семантика, клавиатура, focus, контраст и reduced motion входят в базовые критерии готовности интерфейса.

Используем AI для анализа и ускорения работы, но изменения проходят те же review, тесты и проверку безопасности.

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

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

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

Не рекомендуем: общая схема данных разрушает независимость сервисов и делает миграции и релизы связанными.

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

Не требуем догматичных 100% покрытия: фокус на критичных бизнес-инвариантах, интеграционных и E2E тестах вместо мокания тривиального кода.

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

Не используем многомесячные изолированные ветки: практикуем Trunk-Based Development, короткие PR и feature flags во избежание Merge Hell.