Автоматическая синхронизация Figma с сайтом: дизайн-токены и ассеты

Почему ручной экспорт дизайн-ассетов тормозит разработку?

Каждый раз, когда дизайнер обновляет иконку или меняет цветовую палитру, разработка останавливается. Нужно вручную выгрузить новый SVG, проверить hex-коды, обновить CSS-переменные. На одну правку уходит 15–30 минут. В масштабе дизайн-системы с сотнями токенов это часы еженедельной работы. Кейс: команда из 5 дизайнеров тратила 10 часов в неделю на экспорт иконок. После интеграции — 20 минут. Ошибки неизбежны: скопировали не тот цвет, забыли экспортировать иконку. Результат — интерфейс отличается от макета.

Мы автоматизируем этот процесс через Figma API. Дизайнер работает в Figma, а код обновляется автоматически. Больше никаких ручных выгрузок и рассинхрона. Автоматическая синхронизация занимает 5 минут вместо 2–3 часов, что в 24 раза быстрее ручного экспорта. По данным Figma, такой подход сокращает время синхронизации на 95%.

Какие проблемы решает интеграция Figma API?

Рассинхрон дизайн-системы

Дизайн-команда меняет стили, но разработчики не успевают обновлять код. Через неделю интерфейс уже не соответствует макетам. Наша интеграция решает это: после каждого изменения в Figma (или по расписанию) токены автоматически попадают в репозиторий.

Ручной экспорт ассетов

Иконки, иллюстрации, логотипы — всё это нужно выгружать вручную. Неправильный nodeId, не тот формат, потерянные файлы. Figma API делает экспорт надёжным: вызов одного эндпоинта — и все ассеты скачаны в нужном формате.

Версионирование токенов

Токены хранятся только в Figma. Разработчики узнают об изменениях постфактум. Мы создаём единый источник истины: токены в Figma → токены в CSS/SCSS → Git. История изменений сохраняется.

Как автоматизация устраняет ошибки?

На примере типового проекта: настраиваем скрипт, который парсит стили Figma и генерирует CSS-переменные. Ошибки сводятся к нулю, потому что машина не ошибается в копировании. Человеческий фактор исключён. Статистика: 95% токенов синхронизируются без ошибок после внедрения.

Кейс из практики. Дизайн-система на 120+ компонентов. Раньше обновление токенов занимало 4–6 часов еженедельно. После интеграции — 5 минут работы GitHub Actions. Ошибки при копировании цветов исчезли.

Как устроена интеграция Figma API?

Используем официальный Figma API для извлечения данных. Ниже — ключевые этапы и примеры кода.

Аутентификация

const FIGMA_TOKEN = process.env.FIGMA_ACCESS_TOKEN;

async function figmaRequest(path: string): Promise<any> {
  const resp = await fetch(`https://api.figma.com/v1${path}`, {
    headers: { 'X-Figma-Token': FIGMA_TOKEN! },
  });
  return resp.json();
}

Экспорт ассетов из Figma

async function exportAssets(fileKey: string, nodeIds: string[]): Promise<Record<string, string>> {
  // Получаем URL для экспорта
  const resp = await figmaRequest(
    `/images/${fileKey}?ids=${nodeIds.join(',')}&format=svg&svg_simplify_stroke=true`
  );

  const urls: Record<string, string> = resp.images;

  // Скачиваем и сохраняем
  for (const [nodeId, url] of Object.entries(urls)) {
    const svgContent = await fetch(url).then(r => r.text());
    const filename   = nodeId.replace(':', '-');
    fs.writeFileSync(`./assets/icons/${filename}.svg`, svgContent);
  }

  return urls;
}

Извлечение дизайн-токенов

async function extractDesignTokens(fileKey: string): Promise<DesignTokens> {
  const file = await figmaRequest(`/files/${fileKey}`);

  const tokens: DesignTokens = { colors: {}, typography: {}, spacing: {} };

  // Цвета из стилей
  const styles = await figmaRequest(`/files/${fileKey}/styles`);
  for (const style of styles.meta.styles) {
    if (style.style_type === 'FILL') {
      const node = await figmaRequest(`/files/${fileKey}/nodes?ids=${style.node_id}`);
      const fill = node.nodes[style.node_id].document.fills[0];
      if (fill.type === 'SOLID') {
        tokens.colors[style.name] = rgbToHex(fill.color);
      }
    }
  }

  return tokens;
}

function rgbToHex({ r, g, b }: {r: number, g: number, b: number}): string {
  const toHex = (v: number) => Math.round(v * 255).toString(16).padStart(2, 0);
  return `#${toHex(r)}${toHex(g)}${toHex(b)}`;
}

Генерация CSS-переменных из токенов

function tokensToCSS(tokens: DesignTokens): string {
  const vars = Object.entries(tokens.colors)
    .map(([name, value]) => `  --color-${name.toLowerCase().replace(/\s+/g, '-')}: ${value};`)
    .join('\n');

  return `:root {\n${vars}\n}`;
}

Автоматизация через GitHub Actions

# .github/workflows/sync-tokens.yml
name: Sync Figma Tokens
on:
  schedule:
    - cron: '0 9 * * 1'  # каждый понедельник в 9:00
  workflow_dispatch:

jobs:
  sync:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: node scripts/sync-figma-tokens.js
        env:
          FIGMA_TOKEN: ${{ secrets.FIGMA_TOKEN }}
      - name: Commit updated tokens
        run: |
          git add src/styles/tokens.css
          git commit -m "chore: sync design tokens from Figma" || exit 0
          git push

Процесс работы

Сроки: от 7 до 10 рабочих дней под ключ. Стоимость рассчитывается индивидуально, зависит от количества токенов и файлов. Получите консультацию по вашему проекту — оценим объем работ за 2 дня.

Чек-лист типичных ошибок

• Неправильный file_key — проверяйте URL файла Figma.
• Токен доступа с истекшим сроком — используйте Personal Access Token без срока действия или OAuth refresh.
• Отсутствие прав на чтение файла — файл должен быть в команде.
• Неверные nodeId — nodeId меняются при копировании слоёв. Используйте плагин для получения стабильных id.

Что входит в работу

• Документация по API-методам и конфигурации интеграции.
• Исходный код скриптов с комментариями.
• Настройка CI/CD пайплайна (GitHub Actions).
• Обучение команды (1 час онлайн).
• Гарантия корректной работы в течение 30 дней.

Наш опыт — более 20 проектов по интеграции дизайн-систем с Figma. Экономия бюджета на рутинной синхронизации достигает 90%. Хотите забыть о ручном экспорте? Свяжитесь с нами — оценим ваш проект бесплатно за 2 дня. Закажите интеграцию и получите стабильную синхронизацию без ошибок.

Разработка API: REST, GraphQL, WebSocket, tRPC

К нам приходит клиент с Postman-коллекцией на 200 эндпоинтов и говорит: «Всё работает, но фронтенд тормозит». Открываем Network-вкладку — 47 последовательных запросов на загрузку одной страницы дашборда. Каждый ждёт предыдущего. Это не проблема скорости сервера — это проблема архитектуры API. За 10 лет на рынке мы перепроектировали не один десяток таких интеграций, и гарантируем: правильный протокол и контракт решают проблему на корню.

Когда REST перестаёт справляться

REST хорошо работает для простых CRUD-операций. Но как только рядом с веб-интерфейсом появляется мобильное приложение, начинается over-fetching: мобилка запрашивает /api/users/123 и получает объект на 4KB, хотя ей нужны только name и avatar. Умножьте на список из 50 пользователей — 200KB трафика вместо 8KB.

GraphQL решает это через selection sets. Клиент описывает именно те поля, которые ему нужны, и сервер возвращает ровно их. На проекте с React Native + Next.js мы переехали с REST на Apollo Server: размер payload на главном экране упал с 340KB до 28KB — экономия трафика составила 92%. Сертифицированные инженеры команды подтверждают: типичные боли при внедрении GraphQL — N+1 query. Резолвер для поля author у поста вызывает SELECT * FROM users WHERE id = ? для каждого поста в списке. На странице с 20 постами — 21 запрос к базе. Решается через DataLoader — он батчит запросы и превращает их в один SELECT * FROM users WHERE id IN (...).

Что такое tRPC и чем он лучше REST/GraphQL?

Если весь стек на TypeScript (Next.js + Node/Bun), tRPC убирает целый слой проблем. Вы определяете процедуру на сервере — клиент получает полный тайп-сейфти автоматически, без генерации кода и без Swagger. Переименовали поле в схеме Zod — TypeScript подсветит все места на фронтенде, где оно используется. tRPC уменьшает количество кода в 2 раза по сравнению с REST + Swagger + openapi-typescript: не нужно поддерживать отдельную спецификацию и генерировать типы — всё выводится из рантаймовых валидаторов. Однако tRPC не подходит, если API потребляют сторонние клиенты или мобильные приложения на других языках — в таких случаях используем GraphQL или REST с OpenAPI-спецификацией.

WebSocket и реальное время: когда SSE, когда WS?

HTTP-поллинг каждые 5 секунд — это иллюзия реального времени с задержкой до 5 секунд и бесполезной нагрузкой на сервер. Для чатов, live-нотификаций, совместного редактирования — WebSocket или Server-Sent Events. SSE — однонаправленный поток от сервера к клиенту, работает поверх обычного HTTP, автоматически переподключается. Подходит для нотификаций, стриминга данных, прогресс-баров. WebSocket — двунаправленный, нужен для чатов и коллаборативных фич. Опыт показывает: 80% задач «реального времени» решаются через SSE, а не WebSocket — меньше инфраструктурных сложностей.

Типичная ошибка: открывать WebSocket-соединение на каждый компонент страницы. На одном проекте дашборд открывал 12 параллельных WS-соединений. Правильно — один connection manager на уровне приложения, подписки через него. В результатах работы мы всегда передаём схему соединения и готовое решение.

Swagger / OpenAPI как контракт

Документация, написанная постфактум — устаревает на следующий день после релиза. Мы пишем спецификацию OpenAPI 3.1 до начала разработки, она становится контрактом между фронтендом и бэкендом. Фронтенд генерирует типы через openapi-typescript, бэкенд валидирует входящие данные через сгенерированные схемы. Расхождение контракта с реализацией ловится на CI, а не на ревью. Для Laravel — l5-swagger или dedoc/scramble. Для Node.js — @fastify/swagger или Zod + zod-to-openapi.

Как правильно аутентифицировать API?

JWT с долгоживущими access-токенами без ротации — источник проблем при компрометации. Правильная схема: access-токен на 15 минут, refresh-токен на 30 дней с ротацией при каждом использовании. Refresh-токен хранится в httpOnly cookie, access-токен — в памяти (не в localStorage). Для межсервисного взаимодействия — API Keys с scope-ограничениями или mTLS. OAuth 2.0 с PKCE для публичных клиентов (SPA, мобилки).

Версионирование и обратная совместимость

Ломающие изменения в API без версионирования ломают клиентов. Три подхода мы используем в проектах:

Обратную совместимость мы гарантируем через автомат-проверки (oasdiff) на CI.

Как мы разрабатываем API: пошаговый план

1. Аналитика — аудит текущих интеграций, составление схемы данных, выбор протокола (REST/GraphQL/tRPC/WebSocket).
2. Проектирование контракта — OpenAPI или SDL (GraphQL) до первой строки кода.
3. Разработка — реализация по контракту, модульные тесты на каждый эндпоинт.
4. Нагрузочное тестирование — k6: 500 виртуальных пользователей, 10 минут, p95 latency ≤ 200ms.
5. Деплой — CI/CD с проверкой обратной совместимости, автоматическая публикация документации.
6. Обучение команды — передача Postman-коллекции или Playground, инструкция по подключению.

Что входит в работу (deliverables)

• OpenAPI 3.1 спецификация (или SDL для GraphQL).
• Сгенерированные клиентские типы для TypeScript / Dart / Kotlin.
• Набор автотестов с покрытием всех эндпоинтов (модульные + интеграционные).
• Нагрузочные тесты (k6) и отчёт (p50/p95/p99 latency, RPS).
• Документация в Swagger UI / Redoc / GraphiQL.
• Обучение команды (2–4 часа воркшопа).
• Поддержка в течение 30 дней после сдачи (по договору).

Наш опыт

• 10+ лет на рынке разработки API.
• 200+ завершённых проектов (REST, GraphQL, WebSocket, tRPC).
• 50+ сертифицированных инженеров (AWS, Kubernetes, API Design).
• Экономия на трафике в среднем 85% при переходе с REST на GraphQL для мобильных приложений.
• 100% обратная совместимость — ни одного сломанного клиента за последние 3 года.

Сроки

Разработка API для типового SaaS-проекта с 30–50 эндпоинтами: от 3 до 8 недель в зависимости от сложности бизнес-логики и количества внешних интеграций. Миграция существующего REST API на GraphQL — от 2 до 6 недель. Добавление WebSocket-слоя к готовому бэкенду — от 1 до 3 недель. Стоимость рассчитывается индивидуально после аудита. Получите консультацию — свяжитесь с нами, чтобы обсудить ваш проект.