Чем мы работаем
и почему именно этим.
Страница для тех, кто будет читать наш код или поддерживать систему после нас. По каждому слою разобрано, что мы выбрали и почему.
Frontend
Next.js на App Router: серверный рендер там, где важна скорость первой отрисовки, и клиентские острова только там, где нужна интерактивность. TypeScript в строгом режиме: ошибка, пойманная на сборке, обходится дешевле бага, который нашёл клиент.
Backend
Go для сервисов, которые должны держать нагрузку и запускаться за миллисекунды. Один статический бинарник, предсказуемое потребление памяти, читаемый код без магии. Python нужен там, где важна экосистема данных и ИИ.
Данные
PostgreSQL по умолчанию: он умеет больше, чем от него ждут, и почти всегда снимает вопрос о втором хранилище. Redis нужен для очередей, кэша и лимитов. Отдельная векторная база появляется только когда поиск по документам действительно этого требует.
Инфраструктура
Docker и Compose как база: проект должен подниматься одной командой на чужой машине. Kubernetes подключаем только тогда, когда есть кому его эксплуатировать. Метрики и алерты ставим в день запуска, до того как случится первый инцидент.
ИИ
Модель: это один из компонентов системы, и заменяемый. Мы отделяем промпты и данные от кода, замеряем качество на размеченных наборах и держим возможность сменить провайдера. Наблюдаемость обязательна: без журнала диалогов агента нельзя чинить.
Типовой проект
в одной схеме.
Так выглядит система, которую мы разворачиваем чаще всего. Kubernetes появляется здесь только тогда, когда у клиента есть кому его эксплуатировать.
┌──────────────┐пользователь ──▶ │ Caddy / TLS │└──────┬───────┘┌────────┴────────┐▼ ▼┌─────────────┐ ┌─────────────┐│ Next.js │ │ Go API ││ SSR / ISR │ │ chi/v5 │└─────────────┘ └──────┬──────┘┌───────┼───────┐▼ ▼ ▼┌────────┐ ┌─────┐ ┌───────┐│Postgres│ │Redis│ │ MinIO │└────────┘ └──┬──┘ └───────┘▼┌─────────────┐│ воркер ││ почта · TG │└─────────────┘
Четыре решения,
принятые заранее.
Скучные технологии по умолчанию
Новое берём, когда оно решает нашу конкретную проблему лучше существующего. Сомнение решается в пользу инструмента, который уже стоит у нас в проде.
Стек клиента важнее нашего
Если у вас есть работающая команда на другом стеке, пишем на вашем. Оставить систему, которую некому поддерживать, дороже любой экономии на разработке.
Одна команда для запуска
Проект должен подниматься на чистой машине через docker compose up. Если для запуска нужен человек с особым знанием, это дефект, и мы его чиним до сдачи.
Наблюдаемость с первого дня
Метрики, логи и алерты ставятся до запуска. Систему, о состоянии которой узнаёшь от клиента, нельзя назвать работающей.
Хотите обсудить
архитектуру до брифа?
Напишите нам, разберём вашу схему и скажем, где в ней узкое место. Это бесплатно и ни к чему не обязывает.