Налаштування 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 приносить відчутну економію часу та ресурсів. Ми готові допомогти з впровадженням — зв'яжіться для консультації.

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

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

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

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

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

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

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.