Розробка gRPC API для мікросервісів та веб-застосунків

Розробка gRPC API для мікросервісів та веб-застосунків

Уявіть: мікросервісна архітектура з десятків сервісів, кожен спілкується по REST, але зі зростанням навантаження починаються проблеми — затримки зростають, а помилки типізації час від часу прориваються в продакшен. Інтеграція вимагає постійного узгодження контрактів, а для real-time функціональності доводиться винаходити велосипеди з WebSocket. Ми пройшли цей шлях не раз, і gRPC став для нас стандартним інструментом для внутрішніх API.

gRPC — RPC-фреймворк від Google на основі Protocol Buffers та HTTP/2. Він забезпечує строгу типізацію через .proto-файли, двонаправлений стрімінг та значно менший overhead порівняно з JSON. Найбільш доречний для міжсервісної взаємодії та мобільних клієнтів з обмеженим каналом.

Чому gRPC швидший за REST?

Продуктивність gRPC у 5–10 разів вища на великих повідомленнях завдяки бінарній упаковці та HTTP/2 мультиплексуванню. У наших навантаженнях перехід з REST на gRPC скоротив час відповіді з 45 мс до 8 мс, а трафік зменшився на 60% через компактні протобуфери. Це особливо критично для сервісів з високою частотою запитів — наприклад, агрегаторів даних або платіжних систем.

Що таке Protocol Buffers?

Контракт сервісу визначається у .proto файлах:

syntax = "proto3";
package articles.v1;

import "google/protobuf/timestamp.proto";

message Article {
  string id = 1;
  string title = 2;
  string body = 3;
  string author_id = 4;
  repeated string tag_ids = 5;
  google.protobuf.Timestamp created_at = 6;
}

message GetArticleRequest { string id = 1; }
message ListArticlesRequest {
  int32 page = 1;
  int32 limit = 2;
  string status = 3;
}
message ListArticlesResponse {
  repeated Article articles = 1;
  int32 total = 2;
}

service ArticleService {
  rpc GetArticle(GetArticleRequest) returns (Article);
  rpc ListArticles(ListArticlesRequest) returns (ListArticlesResponse);
  rpc CreateArticle(CreateArticleRequest) returns (Article);
  rpc WatchArticle(GetArticleRequest) returns (stream Article);
}

З .proto генерується код для будь-якої мови: protoc --go_out=. --go-grpc_out=.. Генерація клієнтів на TypeScript або Python — пара команд.

Розробка сервера на Go з перехоплювачами

type ArticleServer struct {
    pb.UnimplementedArticleServiceServer
    db *sql.DB
}

func (s *ArticleServer) GetArticle(ctx context.Context, req *pb.GetArticleRequest) (*pb.Article, error) {
    row := s.db.QueryRowContext(ctx, "SELECT id, title, body FROM articles WHERE id = $1", req.Id)
    var a pb.Article
    if err := row.Scan(&a.Id, &a.Title, &a.Body); err != nil {
        if errors.Is(err, sql.ErrNoRows) {
            return nil, status.Error(codes.NotFound, "article not found")
        }
        return nil, status.Error(codes.Internal, err.Error())
    }
    return &a, nil
}

// Запуск сервера
lis, _ := net.Listen("tcp", ":50051")
grpcServer := grpc.NewServer(grpc.UnaryInterceptor(authInterceptor))
pb.RegisterArticleServiceServer(grpcServer, &ArticleServer{db: db})
grpcServer.Serve(lis)

Перехоплювачі — аналог middleware: автентифікація, логування, трасування (OpenTelemetry), rate limiting. Приклад перехоплювача:

func authInterceptor(ctx context.Context, req any, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (any, error) {
    md, ok := metadata.FromIncomingContext(ctx)
    if !ok {
        return nil, status.Error(codes.Unauthenticated, "missing metadata")
    }
    token := md.Get("authorization")
    if !validateToken(token[0]) {
        return nil, status.Error(codes.Unauthenticated, "invalid token")
    }
    return handler(ctx, req)
}

Ми налаштовуємо ланцюжок перехоплювачів, щоб ізолювати наскрізну функціональність від бізнес-логіки.

Як gRPC підтримує стрімінг?

gRPC пропонує чотири типи взаємодії:

// Unary (звичайний запит/відповідь)
rpc GetArticle(Request) returns (Response);

// Server streaming (один запит → потік відповідей)
rpc WatchUpdates(Request) returns (stream Event);

// Client streaming (потік запитів → одна відповідь)
rpc UploadChunks(stream Chunk) returns (UploadResult);

// Bidirectional streaming
rpc Chat(stream Message) returns (stream Message);

Серверний стрімінг зручний для real-time сповіщень, експорту великих обсягів даних і live-результатів пошуку. В одному з проєктів для IoT-платформи ми використовували bidirectional streaming для передачі телеметрії від сотень пристроїв — затримка склала менше 20 мс.

gRPC у браузері та сучасні альтернативи

Напряму gRPC не працює в браузері через обмеження HTTP/2 binary framing. Рішення:

• gRPC-Web — спеціальний протокол з Envoy proxy на стороні сервера.
• Connect (Buf) — сучасна альтернатива, яка працює з HTTP/1.1 і HTTP/2, сумісна з gRPC.

buf generate --template buf.gen.yaml

Buf також надає Schema Registry для централізованого зберігання .proto-файлів і версіонування контрактів.

Що входить у розробку gRPC API?

Як розробити gRPC API: покрокова інструкція

1. Визначте контракти у .proto файлах, продумайте всі типи повідомлень і RPC-методи.
2. Згенеруйте код сервера та клієнта за допомогою protoc або buf generate.
3. Реалізуйте бізнес-логіку сервера, впровадьте перехоплювачі для автентифікації та логування.
4. Налаштуйте стрімінг, якщо потрібна real-time передача даних.
5. Інтегруйте з gRPC-Web або Connect, якщо клієнти працюють з браузера.
6. Протестуйте API за допомогою gRPCurl або Postman, перевірте типобезпеку.
7. Задеплойте сервіси в Kubernetes, підключіть моніторинг через OpenTelemetry.

grpcurl -plaintext localhost:50051 articles.v1.ArticleService/GetArticle

Порівняння gRPC та REST

Джерело: офіційна документація gRPC

Коли обрати gRPC?

gRPC виправданий при міжсервісній взаємодії всередині інфраструктури, коли потрібен строгий контракт між командами, для ефективного бінарного протоколу в IoT і мобільних застосунках, а також якщо потрібен двонаправлений стрімінг. Для публічних API та браузерних клієнтів без gRPC-Web частіше підходять REST або GraphQL. Замовте консультацію — допоможемо визначитися з вибором.

Наш досвід

Понад 10 років ми розробляємо високонавантажені API для fintech, e-commerce та IoT. У портфоліо — 50+ успішних проєктів на Go та TypeScript. Ми гарантуємо надійність та продуктивність вашого gRPC-рішення. Зв'яжіться з нами для оцінки вашого проєкту.

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