Розробка SDK/бібліотеки для інтеграцій з SaaS-застосунком

Реалізація SDK-бібліотеки для інтеграцій з вашим SaaS-застосунком прискорює онбординг партнерів. Уявіть: ви запускаєте SaaS-продукт, і перші клієнти скаржаться, що інтеграція з API займає тижні. Вони вручну шлють HTTP-запити, обробляють помилки, пишуть власну пагінацію. Бар'єр входу занадто високий. Ми вирішуємо цю проблему розробкою клієнтського SDK — готової бібліотеки, яка знижує час інтеграції до годин. Наш досвід — 7+ років у створенні SDK для B2B SaaS, понад 50 успішних проєктів. У той час як самостійна розробка SDK обходиться в $3k–$5k лише на зарплату розробника, наш SDK під ключ коштує в 2–3 рази дешевше.

Як SDK прискорює інтеграцію?

SDK інкапсулює типові завдання: авторизація, ретраї з exponential backoff, пагінація, верифікація вебхуків. Розробнику потрібно лише встановити пакет і викликати методи. Замість 500 рядків коду — 5 рядків. Це скорочує час виведення на ринок (TTM) на 80%.

Чому варто замовити SDK у професіоналів?

Самостійна розробка SDK потребує часу та знань: потрібно правильно організувати ретраї, уникнути race conditions, підтримувати зворотну сумісність. Ми вже зробили це десятки разів. Використовуємо перевірені паттерни: Repository, BFF, типізовані відповіді. Гарантуємо стабільність та повну документацію. Нижче — порівняльна таблиця якості.

Структура SDK-проєкту

my-api-sdk/
  src/
    client.ts          # Основний HTTP-клієнт
    resources/
      users.ts         # Ресурс: користувачі
      projects.ts      # Ресурс: проєкти
      webhooks.ts      # Верифікація webhook
    types/
      index.ts         # Усі публічні типи
      responses.ts     # Типи відповідей API
    errors.ts          # Кастомні помилки
    retry.ts           # Retry логіка
    pagination.ts      # Pager для списків
  tests/
    client.test.ts
  dist/                # Скомпільований JS + типи
  package.json
  tsconfig.json
  README.md

HTTP-клієнт

// src/client.ts
export interface MyApiConfig {
  apiKey: string;
  baseUrl?: string;
  timeout?: number;
  maxRetries?: number;
}

export class MyApiError extends Error {
  constructor(
    message: string,
    public readonly statusCode: number,
    public readonly code: string,
    public readonly requestId: string
  ) {
    super(message);
    this.name = 'MyApiError';
  }
}

export class MyApiClient {
  private readonly baseUrl: string;
  private readonly apiKey: string;
  private readonly timeout: number;
  private readonly maxRetries: number;

  // Ресурси
  public readonly users: UsersResource;
  public readonly projects: ProjectsResource;
  public readonly webhooks: WebhooksResource;

  constructor(config: MyApiConfig) {
    this.baseUrl = config.baseUrl ?? 'https://api.myproduct.com/v1';
    this.apiKey = config.apiKey;
    this.timeout = config.timeout ?? 30_000;
    this.maxRetries = config.maxRetries ?? 3;

    this.users = new UsersResource(this);
    this.projects = new ProjectsResource(this);
    this.webhooks = new WebhooksResource(this);
  }

  async request<T>(
    method: string,
    path: string,
    options: RequestOptions = {}
  ): Promise<T> {
    const url = `${this.baseUrl}${path}`;
    const headers: Record<string, string> = {
      'Authorization': `Bearer ${this.apiKey}`,
      'Content-Type': 'application/json',
      'User-Agent': `myapi-sdk-node/${SDK_VERSION}`,
      'X-SDK-Version': SDK_VERSION,
    };

    let lastError: Error | undefined;

    for (let attempt = 0; attempt <= this.maxRetries; attempt++) {
      if (attempt > 0) {
        // Exponential backoff: 1s, 2s, 4s
        await new Promise(resolve => setTimeout(resolve, 2 ** (attempt - 1) * 1000));
      }

      try {
        const controller = new AbortController();
        const timeoutId = setTimeout(() => controller.abort(), this.timeout);

        const response = await fetch(url, {
          method,
          headers,
          body: options.body ? JSON.stringify(options.body) : undefined,
          signal: controller.signal,
        });

        clearTimeout(timeoutId);

        const requestId = response.headers.get('x-request-id') ?? 'unknown';

        if (!response.ok) {
          const error = await response.json().catch(() => ({}));

          // Не ретраїмо клієнтські помилки
          if (response.status < 500) {
            throw new MyApiError(
              error.message ?? 'API Error',
              response.status,
              error.code ?? 'UNKNOWN',
              requestId
            );
          }

          lastError = new MyApiError(
            error.message ?? 'Server Error',
            response.status,
            error.code ?? 'SERVER_ERROR',
            requestId
          );
          continue;
        }

        if (response.status === 204) return undefined as T;
        return response.json();
      } catch (error) {
        if (error instanceof MyApiError) throw error;
        lastError = error as Error;
      }
    }

    throw lastError;
  }
}

Ресурс з пагінацією

// src/resources/projects.ts
export interface Project {
  id: string;
  name: string;
  status: 'active' | 'archived';
  createdAt: string;
}

export interface ListProjectsParams {
  limit?: number;
  cursor?: string;
  status?: 'active' | 'archived';
}

export interface PaginatedResponse<T> {
  data: T[];
  nextCursor?: string;
  hasMore: boolean;
  total: number;
}

export class ProjectsResource {
  constructor(private client: MyApiClient) {}

  async list(params: ListProjectsParams = {}): Promise<PaginatedResponse<Project>> {
    const query = new URLSearchParams();
    if (params.limit) query.set('limit', params.limit.toString());
    if (params.cursor) query.set('cursor', params.cursor);
    if (params.status) query.set('status', params.status);

    return this.client.request('GET', `/projects?${query}`);
  }

  // Auto-paging iterator
  async *listAll(params: Omit<ListProjectsParams, 'cursor'> = {}): AsyncIterable<Project> {
    let cursor: string | undefined;

    do {
      const page = await this.list({ ...params, cursor, limit: params.limit ?? 100 });
      yield* page.data;
      cursor = page.nextCursor;
    } while (cursor);
  }

  async create(data: { name: string; description?: string }): Promise<Project> {
    return this.client.request('POST', '/projects', { body: data });
  }

  async get(id: string): Promise<Project> {
    return this.client.request('GET', `/projects/${id}`);
  }

  async update(id: string, data: Partial<Pick<Project, 'name' | 'status'>>): Promise<Project> {
    return this.client.request('PATCH', `/projects/${id}`, { body: data });
  }

  async delete(id: string): Promise<void> {
    return this.client.request('DELETE', `/projects/${id}`);
  }
}

Верифікація webhook

// src/resources/webhooks.ts
import { createHmac, timingSafeEqual } from 'crypto';

export class WebhooksResource {
  constructor(private client: MyApiClient) {}

  verify(payload: string | Buffer, signature: string, secret: string): boolean {
    const expectedSignature = 'sha256=' + createHmac('sha256', secret)
      .update(payload)
      .digest('hex');

    const sigBuffer = Buffer.from(signature);
    const expectedBuffer = Buffer.from(expectedSignature);

    if (sigBuffer.length !== expectedBuffer.length) return false;
    return timingSafeEqual(sigBuffer, expectedBuffer);
  }

  constructEvent(
    payload: string,
    signature: string,
    secret: string
  ): WebhookEvent {
    if (!this.verify(payload, signature, secret)) {
      throw new Error('Invalid webhook signature');
    }
    return JSON.parse(payload);
  }
}

Порівняння: самостійна розробка vs SDK під ключ

Як ми це робимо: реальний кейс

Клієнт — SaaS-платформа для управління проєктами. Їх REST API використовували 10 партнерів, кожен писав свою інтеграцію. Ми за 4 дні розробили SDK на TypeScript, опублікували в npm. Скоротили час інтеграції для партнерів з 3 днів до 2 годин. Партнери просто встановлювали пакет і викликали методи. Ретроспективно: клієнти оцінили зниження TTM та кількість багів.

Процес роботи

1. Аналітика: вивчаємо ваше API, OpenAPI-специфікацію, вимоги до SDK.
2. Проектування: визначаємо структуру ресурсів, інтерфейси, публічний API.
3. Реалізація: пишемо клієнт, ресурси, пагінацію, вебхуки, тести.
4. Збірка та публікація: налаштовуємо tsup, готуємо npm-пакет.
5. Передача: вихідний код, документація, консультації.

Розробка TypeScript SDK з авторетраями, пагінацією та публікацією в npm — 3–5 робочих днів. Реалізація SDK спрощує інтеграції з вашим SaaS-застосунком в рази швидше самостійного підходу.

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

За даними State of API Report 2023, 63% розробників називають якість SDK ключовим фактором при виборі платформи. Ми враховуємо це при кожній реалізації.

• Аналіз вашого API та OpenAPI-специфікації — визначаємо ресурси та публічний інтерфейс.
• Розробка типізованого HTTP-клієнта на TypeScript з ретраями та таймаутами.
• Реалізація пагінації (cursor-based), верифікації вебхуків та обробки помилок.
• Тести (vitest/jest) з покриттям ≥80% публічного API.
• Збірка (tsup) та публікація в npm з підтримкою ESM та CJS.
• Документація: README з прикладами, CHANGELOG, migration guide.
• Консультація команди замовника по інтеграції.

Вартість базового TypeScript SDK для REST API — від 50 000 ₽. SDK з GraphQL, стримінгом або OAuth 2.0 — від 90 000 ₽. Точну оцінку даємо за 1 робочий день після аудиту вашого API.

Зв'яжіться з нами — ми оцінимо ваш проєкт і запропонуємо оптимальне рішення. Замовте SDK під ключ і прискорте інтеграцію вашого продукту.

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