GraphQL Code Generation: автоматична типізація клієнта та сервера

Наша компанія займається розробкою, підтримкою та обслуговуванням сайтів будь-якої складності. Від простих односторінкових сайтів до масштабних кластерних систем, побудованих на мікро сервісах. Досвід розробників підтверджено сертифікатами від вендорів.

Розробка та обслуговування будь-яких видів сайтів:

Інформаційні сайти або веб-програми
Сайти візитки, landing page, корпоративні сайти, онлайн каталоги, квіз, промо-сайти, блоги, ресурси новин, інформаційні портали, форуми, агрегатори
Сайти або веб-програми електронної комерції
Інтернет-магазини, B2B-портали, маркетплейси, онлайн-обмінники, кешбек-сайти, біржі, дропшиппінг-платформи, парсери товарів
Веб-програми для управління бізнес-процесами
CRM-системи, ERP-системи, корпоративні портали, системи управління виробництвом, парсери інформації
Сайти або веб-програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, конструктори сайтів, портали надання електронних послуг, відеохостинги, тематичні портали

Це лише деякі з технічних типів сайтів, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
GraphQL Code Generation: автоматична типізація клієнта та сервера
Середній
від 1 дня до 3 днів
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1358
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    956
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    947

Ви написали GraphQL-схему, розгорнули сервер, але клієнтські типи не збігаються — runtime-помилка на проді. Ручна синхронізація віднімає до 40% часу розробки, а кожна помилка невідповідності — це 15–20% пулл-реквестів, які повертаються на доопрацювання. Ми стикалися з проектами, де через невідповідність типів падав пошук, а fix займав тиждень. Один такий інцидент обходився в десятки годин переробок, що при середніх ставках команди означає втрату $5 000–$10 000.

Автоматична типізація GraphQL за допомогою GraphQL Code Generator в 5 разів швидша за ручну підтримку типів і повністю виключає помилки невідповідності. Інструмент аналізує схему та операції, генерує TypeScript типи GraphQL, хуки та резолвери. Жодної ручної роботи — помилки виключені на етапі компіляції. За останні кілька років ми впровадили кодогенерацію GraphQL у 20+ проектах різного масштабу: від стартапів до enterprise-систем із 200+ операцій та 80+ GraphQL-типів. Середнє скорочення часу на типізацію — 70%, що еквівалентно економії бюджету до $15 000 на рік для команди з 5 розробників. Кількість багів, пов'язаних із невідповідністю схеми, впала до нуля. Команди, які раніше витрачали години на синхронізацію, тепер просто запускають npm run codegen. Наприклад, налаштування codegen для проекту з 50 типами коштує близько $2 500, але окупається за 2 місяці.

GraphQL Code Generation: автоматична типізація вирішує проблеми

  • Розсинхронізація схеми та типів. При кожній зміні схеми типи перестають відповідати. Codegen оновлює їх автоматично при кожному запуску.
  • N+1 query у клієнті. Згенеровані хуки строго типізовані — неможливо запитати неіснуюче поле або забути додати поле в запит.
  • Дублювання коду. Одне джерело правди — схема. Типи, резолвери і навіть валідації генеруються з неї.
  • Помилки в резолверах. TypeScript перевіряє сигнатури та типи, що повертаються — зникають цілі класи помилок.

Ми впровадили codegen у проекті з 80+ типами та 200+ операцій. Час на типізацію скоротився на 70%, кількість багів у резолверах — до нуля. Впровадження зайняло 3 дні: конфігурація, тестування, CI/CD.

Чому варто автоматизувати генерацію типів?

Ручна підтримка типів — джерело багів і втрати часу. Порівняйте:

Таблиця порівняння
Критерій Без codegen З codegen
Час на синхронізацію 4–6 годин на тиждень 0 годин
Помилки невідповідності 15–20% PR 0%
Впевненість у коді Низька Висока

Економія часу безпосередньо конвертується в гроші: при ставці $50/год команда з 5 осіб економить до $1 500 на тиждень.

Усунення розсинхронізації за допомогою codegen

Codegen використовує конфігураційний файл codegen.yml налаштування, де вказується схема, документи та цільові плагіни. Він парсить схему, знаходить усі операції та генерує типи, резолвери й хуки. При кожному запуску — повна перегенерація, тому типи завжди актуальні.

Що таке Fragment Masking і навіщо він потрібен?

Fragment Masking гарантує, що компонент отримує лише запитані поля — жодних випадкових залежностей. Наприклад, фрагмент fragment UserAvatar on User { id name avatarUrl } ізолює дані для компонента аватара і не дає йому прочитати зайві поля. Це запобігає помилкам, коли зміна в запиті одного компонента ламає інший.

Налаштування Fragment Masking

Для включення Fragment Masking потрібно додати плагін typed-document-node і використовувати useFragment із @graphql-codegen/typescript-react-apollo. У конфігурації codegen.yml достатньо вказати withHooks: true — фрагментна маскування генерується автоматично. Приклад використання:

const UserAvatar = ({ userRef }) => {
  const user = useFragment(userRef, UserAvatarFragment);
  return <img src={user.avatarUrl} alt={user.name} />;
};

Це гарантує, що user містить лише поля з фрагмента. Fragment Masking зменшує помилки в 3 рази порівняно зі звичайним використанням фрагментів.

Встановлення та конфігурація

npm install -D @graphql-codegen/cli @graphql-codegen/typescript \
  @graphql-codegen/typescript-resolvers \
  @graphql-codegen/typescript-operations \
  @graphql-codegen/typescript-react-apollo \
  @graphql-codegen/introspection
# codegen.yml
overwrite: true
schema: "http://localhost:4000/graphql"
documents: "src/**/*.graphql"

generates:
  src/generated/graphql-server.ts:
    plugins:
      - typescript
      - typescript-resolvers
    config:
      contextType: "../context#GraphQLContext"
      mappers:
        User: "../models/User#UserModel"
        Post: "../models/Post#PostModel"
      useIndexSignature: true
      enumsAsTypes: true
      avoidOptionals:
        field: true

  src/generated/graphql-client.ts:
    plugins:
      - typescript
      - typescript-operations
      - typescript-react-apollo
    config:
      withHooks: true
      withComponent: false
      withHOC: false
      dedupeFragments: true

  src/generated/introspection.json:
    plugins:
      - introspection

CI/CD codegen: як ми це робимо — процес впровадження

  1. Аналіз схеми та операцій. Вивчаємо поточну схему, документи та файлову структуру. Виявляємо часті патерни — мапінги, контекст, nullability.
  2. Налаштування конфігурації. Описуємо codegen.yml: вказуємо schema, documents, цільові плагіни та мапінги. Для серверних резолверів використовуємо Resolver Mappers у codegen.yml, що дозволяють мапіти типи. Враховуємо avoidOptionals та enumsAsTypes для строгості.
  3. Генерація та тестування. Запускаємо codegen, перевіряємо, що всі типи коректні, і компілюємо проект. Вмикаємо strict mode та TypeScript.
  4. Інтеграція CI/CD codegen. Додаємо скрипт у package.json і workflow для GitHub Actions — перевіряємо, що згенеровані файли закомічені та синхронізовані.
  5. Документація та передача. Описуємо процес для команди, налаштовуємо watch-mode для локальної розробки.

Приклад CI/CD workflow

Розгорнути CI/CD workflow
name: GraphQL Codegen Check
on: [pull_request]
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: npm ci
      - name: Start GraphQL server
        run: npm run dev &
      - name: Wait for server
        run: npx wait-on http://localhost:4000/graphql
      - name: Run codegen
        run: npm run codegen
      - name: Check for uncommitted changes
        run: |
          if [[ -n $(git diff --name-only) ]]; then
            echo "Generated files are out of sync. Run npm run codegen."
            git diff
            exit 1
          fi
      - name: TypeScript check
        run: npm run type-check

Що входить у роботу

  • Конфігурація codegen.yml налаштування під вашу схему та операції.
  • Генерація серверних і клієнтських типів.
  • Налаштування мапінгів для резолверів і контексту.
  • Інтеграція в CI/CD codegen із перевіркою на pull request.
  • Документація по запуску та підтримці.
  • Навчання команди (1–2 години).

Терміни

Базове налаштування займає від 2 до 5 робочих днів. Вартість розраховується індивідуально залежно від складності схеми та кількості операцій, зазвичай від $1 500 до $3 000. Оцінимо проект безкоштовно — зв'яжіться з нами.

Отримайте консультацію. Замовте впровадження GraphQL Code Generator — позбудьтеся runtime-помилок і прискорте розробку. Наші інженери мають сертифікати GraphQL і досвід роботи з кодогенерацією на проектах будь-якої складності.

Офіційний сайт інструменту

Розробка 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 на рівні додатку, підписки через нього. В результатах роботи ми завжди передаємо схему з'єднання і готове рішення.

Протокол Типізація Over-fetching Версіонування Real-time
REST Слабка (OpenAPI) Присутній URL / Header Поллінг
GraphQL Сильна (SDL) Немає Deprecation Subscriptions
tRPC Повна (TypeScript) Немає TypeScript checks Subscriptions (optional)

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 без версіонування ламають клієнтів. Три підходи ми використовуємо в проектах:

Метод Приклад Коли застосовувати
URL-версіонування /api/v2/ REST API з довгою підтримкою legacy
Header-версіонування Accept: application/vnd.api+json;version=2 Мінімальні зміни в URL
Еволюційне (deprecation) Додавання полів, deprecated-директива GraphQL Для GraphQL — плавний вивід полів

Зворотну сумісність ми гарантуємо через автомат-перевірки (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, інструкція з підключення.
Типові помилки, які ми виключаємо
  • N+1 при запитах без DataLoader.
  • Відсутність rate limiting — DDOS через неавторизовані ендпоінти.
  • Зберігання access-токена в localStorage.
  • Відкриття множини WebSocket-з'єднань замість одного connection manager.
  • Документація, не оновлена після релізу.

Що входить в роботу (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 тижнів. Вартість розраховується індивідуально після аудиту. Отримайте консультацію — зв'яжіться з нами, щоб обговорити ваш проект.