Настройка Turborepo Monorepo: параллельная сборка, кеширование и CI

Допустим, ваш билд фронтенда длится 12 минут, а бекенд и фронтенд в разных репозиториях. Общий код дублируется, задачи CI выполняются последовательно. Это типичная ситуация, которую мы решаем настройкой Turborepo monorepo. Мы сталкивались с проектами, где сборка занимала 30 минут, и Turborepo сократил это до 5. Правильная конфигурация сокращает время сборки в 3–5 раз за счёт параллелизации и кеширования. После внедрения клиенты сокращают затраты на CI-инфраструктуру на существенную сумму. Мы гарантируем, что ваш проект будет собираться быстрее.

Когда стоит выбирать Turborepo?

npm/yarn/pnpm workspaces уже дают monorepo-структуру, но Turborepo добавляет параллельный запуск с учётом зависимостей, инкрементальный кеш (локальный и удалённый) и граф задач. Если проект небольшой (2–3 пакета) — workspaces достаточно. При 5+ пакетах и CI/CD Turborepo начинает экономить реальное время. Сравнение: при 10 пакетах Turborepo в 4 раза быстрее ручной параллелизации за счёт автоматического вывода порядка сборки.

Почему Turborepo, а не Nx?

Turborepo легче: нет необходимости в генераторах кода и плагинах. Достаточно turbo.json и workspace-протокола. Это идеальный выбор для команд, которые хотят monorepo без избыточности. Nx предлагает больше функций, но Turborepo выигрывает в простоте настройки и скорости работы.

Структура проекта

my-project/
├── apps/
│   ├── web/                 # Next.js фронтенд
│   ├── admin/               # Vite + React admin panel
│   └── api/                 # Node.js/Express backend
├── packages/
│   ├── ui/                  # общие React-компоненты
│   ├── config/
│   │   ├── eslint/          # конфиг ESLint
│   │   ├── typescript/      # базовые tsconfig
│   │   └── tailwind/        # tailwind preset
│   ├── utils/               # общие утилиты (formatDate, etc.)
│   └── types/               # общие TypeScript-типы
├── package.json             # workspaces declaration
├── turbo.json               # конфигурация Turborepo
└── pnpm-workspace.yaml      # если используем pnpm

Почему удалённый кеш критичен для CI?

Локальный кеш работает только на одной машине. Для команды и CI нужен remote cache. Vercel Remote Cache — бесплатно для опенсорса, платно для приватных. Self-hosted вариант через turborepo-remote-cache:

# docker-compose.yml для remote cache сервера
services:
  turbo-cache:
    image: ducktors/turborepo-remote-cache:latest
    ports:
      - "3000:3000"
    environment:
      TURBO_TOKEN: "your-secret-token"
      STORAGE_PROVIDER: "s3"
      S3_BUCKET: "turbo-cache-bucket"
      AWS_ACCESS_KEY_ID: "${AWS_ACCESS_KEY_ID}"
      AWS_SECRET_ACCESS_KEY: "${AWS_SECRET_ACCESS_KEY}"

Таблица 1: Сравнение кеширования: локальный vs удалённый

Таблица 2: Сравнение инструментов monorepo

Конфигурация turbo.json

{
  "$schema": "https://turbo.build/schema.json",
  "globalDependencies": [".env"],
  "pipeline": {
    "build": { "dependsOn": ["^build"], "inputs": ["src/**", "package.json", "tsconfig.json"], "outputs": ["dist/**", ".next/**", "!.next/cache/**"], "env": ["NODE_ENV", "API_URL"] },
    "dev": { "cache": false, "persistent": true },
    "lint": { "inputs": ["src/**", "*.ts", "*.tsx", ".eslintrc*"], "outputs": [] },
    "typecheck": { "dependsOn": ["^build"], "inputs": ["src/**", "tsconfig.json"], "outputs": [] },
    "test": { "dependsOn": ["^build"], "inputs": ["src/**", "test/**", "vitest.config.*"], "outputs": ["coverage/**"], "env": ["TEST_DATABASE_URL"] },
    "test:e2e": { "dependsOn": ["build"], "inputs": ["e2e/**", "playwright.config.*"], "outputs": ["test-results/**"], "cache": false },
    "db:generate": { "cache": false, "inputs": ["prisma/schema.prisma"] }
  }
}

Настройка пакетов и общие конфиги

// packages/ui/package.json
{
  "name": "@acme/ui",
  "version": "0.0.0",
  "private": true,
  "exports": {
    ".": { "import": "./dist/index.js", "types": "./dist/index.d.ts" },
    "./styles": "./dist/styles.css"
  },
  "scripts": { "build": "tsup src/index.ts --format esm --dts", "dev": "tsup src/index.ts --format esm --dts --watch" },
  "devDependencies": { "@acme/eslint-config": "*", "@acme/typescript-config": "*", "tsup": "^8.0.0" },
  "peerDependencies": { "react": "^18.0.0" }
}

Как настроить CI с Turborepo?

# .github/workflows/ci.yml
name: CI
on: [push, pull_request]

jobs:
  ci:
    runs-on: ubuntu-latest
    env:
      TURBO_TOKEN: ${{ secrets.TURBO_TOKEN }}
      TURBO_TEAM: ${{ secrets.TURBO_TEAM }}
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 2 }
      - uses: pnpm/action-setup@v3
        with: { version: 9 }
      - uses: actions/setup-node@v4
        with: { node-version: 20, cache: pnpm }
      - run: pnpm install --frozen-lockfile
      - run: pnpm turbo lint typecheck test --filter=...[HEAD^1]
      - run: pnpm turbo build

Типичные ошибки и их решение

• Не указали env в pipeline — кеш выдаёт старые значения.
• Забыли persistent: true для dev — watcher не запускается.
• Circular dependencies — проверяйте граф зависимостей.
• Отсутствие fetch-depth: 2 в CI — фильтр ...[HEAD^1] не работает.
• Неправильная настройка удалённого кеша — убедитесь, что TURBO_TOKEN и TURBO_TEAM установлены.

Процесс настройки Turborepo под ключ

Мы проводим полный цикл: аудит текущей архитектуры, проектирование структуры monorepo, настройка turbo.json, создание общих пакетов (TypeScript, ESLint, Tailwind), развёртывание удалённого кеша на S3, интеграция с CI/CD, написание документации и обучение команды. Результат: сборка в 3–5 раз быстрее, кеширование на CI, единая кодовая база. Экономия времени разработки может достигать 80%. Получите консультацию нашего инженера — мы поможем ускорить ваш CI.

Сроки и экономия

Настройка с нуля для проекта с 5–8 пакетами занимает два-три дня. Перенос существующего проекта в monorepo — около недели. Стоимость рассчитывается индивидуально в зависимости от сложности и количества пакетов. Гарантируем поддержку после запуска. Наш опыт — более 50 monorepo-проектов, семь лет в веб-разработке.

Как Turborepo ускоряет сборку?

Параллелизация задач на основе графа зависимостей позволяет запускать независимые задачи одновременно. Кеширование результатов (локальное и удалённое) пропускает пересборку неизменившихся пакетов. Встроенный фильтр --filter запускает задачи только для затронутых изменением пакетов и их зависимостей. По данным официальной документации Turborepo, параллелизация сокращает время сборки до 5 раз.

Почему remote cache обязателен для команды?

Без удалённого кеша каждый разработчик и CI-сервер собирают одни и те же пакеты заново. Self-hosted remote cache на S3 или MinIO синхронизирует кеш между всеми участниками. Настройка занимает пару часов, но экономит часы сборки ежедневно. Для коммерческих проектов мы рекомендуем self-hosted решение — оно даёт полный контроль и не зависит от внешнего провайдера.

Заключение

Turborepo — эффективный инструмент для ускорения CI и упрощения работы с monorepo. Правильная настройка с удалённым кешем и грамотным pipeline приносит ощутимую экономию времени и ресурсов. Мы готовы помочь с внедрением — свяжитесь для консультации.

Услуги бэкенд-разработки: Laravel, Node.js, Go, Django, PostgreSQL

На production-сервере в 3:14 ночи очередь Laravel Jobs перестала обрабатываться. 40 000 необработанных задач в Redis. Причина: worker упал из-за memory leak в одном из Jobs (утечка через статическую переменную в Eloquent observer), supervisor не перезапустил его из-за misconfigured stopwaitsecs. Это не гипотетический сценарий — это вторник. Мы разбирали такой инцидент на проекте с нагрузкой 500 RPS: диагностика заняла 4 часа, фикс — 20 минут. Чтобы вы не теряли деньги на простоях, предлагаем услуги бэкенд-разработки с акцентом на production-grade надёжность. Оценим ваш проект за 2 дня.

Backend — это то, что работает когда никто не смотрит. Или не работает. Гарантируем, что у вас будет первый вариант.

Что мы делаем с первого дня правильно

Service Layer поверх Fat Controllers. Controller получает HTTP-запрос, валидирует его через Form Request, передаёт данные в Service, возвращает ответ. Бизнес-логика в Service, не в Controller. Это звучит банально, но большинство legacy-проектов — это контроллеры по 500 строк с SQL-запросами внутри.

Repository Pattern используем осторожно. Если вы просто оборачиваете Model::where(...) в метод репозитория — это бойлерплейт без пользы. Repository оправдан когда: нужно абстрагироваться от источника данных (БД + кеш + внешний API) или когда логика запросов достаточно сложна для изоляции.

Jobs, Events, Listeners. Всё, что можно сделать асинхронно — делаем асинхронно. Отправка email, генерация PDF, синхронизация с внешним API, пересчёт агрегатов — в Queue. Laravel Horizon для мониторинга очередей в Redis: видно throughput, failed jobs, время обработки по очередям.

Как Octane справляется с высокой нагрузкой

Laravel Octane с RoadRunner или Swoole держит приложение в памяти между запросами — убирает overhead bootstrap (загрузка конфигов, автозагрузка классов) на каждый HTTP-запрос. Прирост: 3–8x на синтетических бенчмарках, 2–4x на реальных приложениях. Важно: нельзя хранить состояние между запросами в статических переменных — это приводит именно к таким инцидентам, как в начале. Применяем это в проектах с >1000 RPS.

Что делать с N+1 запросами

N+1 — самая распространённая причина медленных страниц в Laravel-приложениях. Стандартная история: страница работала нормально на dev с 10 записями, на production с 10 000 — 8-секундная загрузка.

Laravel Debugbar в dev-окружении показывает количество запросов на страницу. Более 20 запросов на одну страницу — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профилирования в staging: логирует все запросы, jobs, mail, notifications с детализацией по времени. Цифры: после внедрения eager loading время загрузки страницы падает с 8 с до 0.3 с — в 27 раз.

PostgreSQL: индексы, которые реально нужны

PostgreSQL 14+ — основная БД на всех проектах. Используем связку PgBouncer + PostgreSQL. Опыт 10+ лет, более 50 backend-проектов, 5 лет на рынке.

Как PostgreSQL помогает избежать медленных запросов

Composite indexes для частых WHERE + ORDER BY. Если у вас WHERE user_id = ? AND status = ? ORDER BY created_at DESC — нужен (user_id, status, created_at DESC). Индекс по (user_id) отдельно плохо помогает с сортировкой.

Partial indexes. Если 95% запросов идут по WHERE status = 'active':

CREATE INDEX idx_orders_active ON orders (created_at DESC)
WHERE status = 'active';

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

GIN-индексы для JSONB и массивов. @> оператор без GIN-индекса — seq scan. С индексом — быстро даже на миллионах записей.

GIN для full-text search. to_tsvector + GIN вместо LIKE '%query%'. LIKE без индекса — всегда seq scan. С pg_trgm extension и gin_trgm_ops — поддержка LIKE с индексом, полезно для CRM-поиска по частичному совпадению.

Connection pooling: почему важнее чем кажется

Rails, Laravel, Django открывают новое соединение с PostgreSQL на каждый PHP/Python процесс. На 100 воркерах — 100 соединений. PostgreSQL начинает деградировать от 200–300 активных соединений — overhead на управление соединениями становится значительным.

PgBouncer — connection pooler перед PostgreSQL. Режим transaction pooling: соединение с PostgreSQL занято только на время транзакции, между запросами возвращается в пул. 1000 приложений-воркеров → 20–50 реальных соединений к PostgreSQL. Это снижает latency на 40% и уменьшает затраты на хостинг на 30%.

Node.js с Fastify: когда это лучше Laravel

Node.js оправдан для:

• Realtime: WebSocket-серверы, Server-Sent Events, чат, live-обновления
• Streaming: большие файлы, видео, данные потоком
• High I/O concurrency: много параллельных запросов к внешним API без тяжёлой бизнес-логики
• Serverless: Lambda/Cloud Functions — Node.js стартует быстрее PHP

Fastify вместо Express: в 2–3 раза быстрее на benchmarks, встроенная JSON Schema валидация, лучшая TypeScript поддержка, plugin-архитектура.

Типичная архитектура realtime: Laravel — основная бизнес-логика и REST API. Node.js + Socket.io или ws — WebSocket сервер. Laravel публикует события в Redis Pub/Sub, Node.js подписывается и транслирует клиентам. Это разделение позволяет масштабировать WebSocket-сервер независимо от основного приложения.

Go: микросервисы и высокая нагрузка

Go используем для:

• Высоконагруженных микросервисов (> 10 000 RPS)
• Фоновых воркеров с жёсткими требованиями к latency
• Инструментов DevOps и CLI
• gRPC-сервисов в микросервисной архитектуре

Goroutines — дешевле OS-потоков в тысячи раз. 10 000 конкурентных соединений на Go — норма на одном сервере.

Но Go — не волшебная таблетка. Разработка медленнее чем на Laravel: больше бойлерплейта, нет ORM уровня Eloquent, обработка ошибок через if err != nil везде. Оправдан только когда производительность — реальное требование, не предположение.

Django и Python backend

Django с DRF (Django REST Framework) — для задач где нужен Python: ML-пайплайны, обработка данных, интеграции с AI-инструментами.

Celery для фоновых задач — аналог Laravel Queue, но сложнее в конфигурации. Celery Beat для cron-задач.

Django ORM vs raw SQL: ORM удобен для CRUD. Для аналитических запросов с несколькими JOIN, оконными функциями и CTE — connection.execute() с raw SQL читаемее и предсказуемее.

Redis: не только кеш

Redis в наших проектах выполняет несколько ролей:

Redis Cluster для горизонтального масштабирования. Sentinel для автоматического failover на standalone установках.

Деплой и инфраструктура

Docker + docker-compose — стандарт для локальной разработки и production. Каждый сервис в контейнере: PHP-FPM/Octane, Nginx, PostgreSQL, Redis, Queue Worker, Scheduler.

CI/CD через GitHub Actions:

1. Прогон тестов (PHPUnit / Pest, Vitest, Playwright)
2. Сборка Docker-образа
3. Push в Container Registry
4. Deploy: docker pull → docker-compose up -d на сервере, или Kubernetes rolling update

Zero-downtime deploy для Laravel: php artisan down --secret=TOKEN не нужен при правильной настройке. Стратегия: новый контейнер стартует рядом со старым, Nginx переключает трафик после health check, старый контейнер останавливается.

Мониторинг: Sentry для exception tracking с alerting в Slack/Telegram. Grafana + Prometheus (или Grafana Cloud) для метрик: CPU, memory, request rate, queue depth, database connection count. Алерт на: error rate > 1%, p99 latency > 2s, queue depth > 1000 jobs.

Что входит в работу под ключ

• Архитектурное проектирование (документация API, схема БД, диаграмма сервисов)
• Реализация по согласованному ТЗ с code review
• Настройка CI/CD, мониторинга, алертинга
• Нагрузочное тестирование (k6, wrk) с отчётом
• Передача исходников, доступов, инструкция по деплою
• Обучение команды заказчика (2-3 сессии)
• Гарантийная поддержка 1 месяц после сдачи

Ориентиры по срокам

Стоимость рассчитывается индивидуально после анализа требований к нагрузке, интеграциям и бизнес-логике. Типичный бюджет backend-проекта — от 500 000 до 2 000 000 рублей в зависимости от сложности. Свяжитесь с нами для бесплатного аудита вашего текущего backend — получите план оптимизации за 2 дня. Закажите консультацию.