gRPC API Development for Microservices and Web Apps

gRPC API Development for Microservices and Web Apps

Imagine a microservice architecture with dozens of services, each communicating via REST. As load grows, problems arise — latency increases, type errors sneak into production, and integration requires constant contract negotiation. For real-time functionality, you have to reinvent the wheel with WebSocket. We've been down this path multiple times, and gRPC has become our standard tool for internal APIs.

gRPC is an RPC framework from Google based on Protocol Buffers and HTTP/2. It provides strict typing via .proto files, bidirectional streaming, and significantly lower overhead compared to JSON. It's most suitable for inter-service communication and mobile clients with limited bandwidth.

Why gRPC is Faster Than REST

Performance of gRPC is 5–10 times higher on large messages thanks to binary packing and HTTP/2 multiplexing. In our workloads, switching from REST to gRPC reduced response time from 45 ms to 8 ms, and traffic decreased by 60% due to compact protobufs. This is especially critical for services with high request frequency — for example, data aggregators or payment systems.

What Are Protocol Buffers?

The service contract is defined in .proto files:

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);
}

Code is generated from .proto for any language: protoc --go_out=. --go-grpc_out=.. Generating clients for TypeScript or Python is a couple of commands.

Server Implementation in Go with Interceptors

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
}

// Starting the server
lis, _ := net.Listen("tcp", ":50051")
grpcServer := grpc.NewServer(grpc.UnaryInterceptor(authInterceptor))
pb.RegisterArticleServiceServer(grpcServer, &ArticleServer{db: db})
grpcServer.Serve(lis)

Interceptors are analogous to middleware: authentication, logging, tracing (OpenTelemetry), rate limiting. Example interceptor:

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)
}

We configure a chain of interceptors to isolate cross-cutting concerns from business logic.

How gRPC Supports Streaming

gRPC offers four interaction types:

// Unary (standard request/response)
rpc GetArticle(Request) returns (Response);

// Server streaming (one request → stream of responses)
rpc WatchUpdates(Request) returns (stream Event);

// Client streaming (stream of requests → one response)
rpc UploadChunks(stream Chunk) returns (UploadResult);

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

Server streaming is convenient for real-time notifications, exporting large volumes of data, and live search results. On one IoT platform project, we used bidirectional streaming for telemetry transmission from hundreds of devices — latency was under 20 ms.

gRPC in the Browser and Modern Alternatives

gRPC doesn't work directly in the browser due to HTTP/2 binary framing limitations. Solutions:

• gRPC-Web — a special protocol with an Envoy proxy on the server side.
• Connect (Buf) — a modern alternative that works with HTTP/1.1 and HTTP/2, compatible with gRPC.

buf generate --template buf.gen.yaml

Buf also provides a Schema Registry for centralized storage of .proto files and contract versioning.

What's Included in gRPC API Development

How to Develop a gRPC API: Step-by-Step Guide

1. Define contracts in .proto files, design all message types and RPC methods.
2. Generate server and client code using protoc or buf generate.
3. Implement server business logic, add interceptors for authentication and logging.
4. Set up streaming if real-time data transfer is required.
5. Integrate with gRPC-Web or Connect if clients are browser-based.
6. Test the API with gRPCurl or Postman, verify type safety.
7. Deploy services to Kubernetes, connect monitoring via OpenTelemetry.

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

gRPC vs REST: Comparison

Source: official gRPC documentation

When to Choose gRPC?

gRPC is justified for inter-service communication within one infrastructure, when a strict contract between teams is needed, for efficient binary protocol in IoT and mobile apps, and when bidirectional streaming is required. For public APIs and browser clients without gRPC-Web, REST or GraphQL are usually better choices. Request a consultation — we'll help you decide.

Our Experience

With over 10 years of experience building high-load APIs for fintech, e-commerce, and IoT, and a portfolio of 50+ successful projects in Go and TypeScript, we guarantee reliability and performance for your gRPC solution. Contact us for a project assessment.

API Development with REST, GraphQL, WebSocket, and tRPC

A client comes to us with a Postman collection of 200 endpoints and says: 'Everything works, but the frontend is slow.' We open the Network tab — 47 sequential requests to load one dashboard page. Each one waits for the previous. This is not a server speed issue — it's an API architecture problem. With 10 years on the market, we've redesigned dozens of such integrations, and we guarantee: the right protocol and contract solve the problem at its root.

When REST stops being enough

REST works well for simple CRUD operations. But as soon as a mobile app appears alongside the web interface, over-fetching begins: the mobile app requests /api/users/123 and gets a 4KB object, but only needs name and avatar. Multiply that by a list of 50 users — 200KB traffic instead of 8KB.

GraphQL solves this with selection sets. The client describes exactly the fields it needs, and the server returns only those. On a project with React Native + Next.js, we migrated from REST to Apollo Server: payload size on the main screen dropped from 340KB to 28KB — a 92% traffic savings. Our certified engineers confirm: the typical pain when adopting GraphQL is N+1 query. A resolver for the author field on a post calls SELECT * FROM users WHERE id = ? for each post in the list. On a page with 20 posts — 21 database queries. Solved with DataLoader — it batches queries and turns them into one SELECT * FROM users WHERE id IN (...).

What is tRPC and how is it better than REST/GraphQL?

If the entire stack is TypeScript (Next.js + Node/Bun), tRPC removes a whole layer of problems. You define a procedure on the server — the client gets full type-safety automatically, without code generation and without Swagger. Renamed a field in the Zod schema — TypeScript highlights all places on the frontend where it's used. tRPC reduces code by 2 times compared to REST + Swagger + openapi-typescript: no need to maintain a separate specification and generate types — everything is inferred from runtime validators. However, tRPC is not suitable if the API is consumed by third-party clients or mobile apps in other languages — in such cases we use GraphQL or REST with OpenAPI specification.

WebSocket and real-time: when SSE, when WS?

HTTP polling every 5 seconds is an illusion of real-time with up to 5 seconds delay and useless server load. For chats, live notifications, collaborative editing — WebSocket or Server-Sent Events. SSE is a one-way stream from server to client, works over ordinary HTTP, automatically reconnects. Suitable for notifications, data streaming, progress bars. WebSocket is bidirectional, needed for chats and collaborative features. Experience shows: 80% of 'real-time' tasks are solved with SSE, not WebSocket — fewer infrastructure complexities.

A typical mistake: opening a WebSocket connection for each page component. On one project, the dashboard opened 12 parallel WS connections. The correct approach is one connection manager at the application level, subscriptions through it. In our work results, we always transfer the connection scheme and a ready solution.

Swagger / OpenAPI as a contract

Documentation written after the fact becomes outdated the day after release. We write the OpenAPI 3.1 specification before development starts; it becomes the contract between frontend and backend. The frontend generates types via openapi-typescript, the backend validates incoming data using generated schemas. Contract deviation from implementation is caught on CI, not during review. For Laravel — l5-swagger or dedoc/scramble. For Node.js — @fastify/swagger or Zod + zod-to-openapi.

How to properly authenticate an API?

JWT with long-lived access tokens without rotation is a source of problems when compromised. The correct scheme: access token for 15 minutes, refresh token for 30 days with rotation on each use. Refresh token stored in an httpOnly cookie, access token in memory (not in localStorage). For inter-service communication — API Keys with scope limitations or mTLS. OAuth 2.0 with PKCE for public clients (SPA, mobile).

How to handle versioning and backward compatibility?

Breaking changes in an API without versioning break clients. Three approaches we use in projects:

We guarantee backward compatibility through automated checks (oasdiff) on CI.

How we develop APIs: step-by-step plan

1. Analysis — audit of current integrations, data schema compilation, protocol selection (REST/GraphQL/tRPC/WebSocket).
2. Contract design — OpenAPI or SDL (GraphQL) before the first line of code.
3. Development — implementation per contract, unit tests for each endpoint.
4. Load testing — k6: 500 virtual users, 10 minutes, p95 latency ≤ 200ms.
5. Deployment — CI/CD with backward compatibility check, automatic documentation publication.
6. Team training — handover of Postman collection or Playground, connection instructions.

What is included (deliverables)

• OpenAPI 3.1 specification (or SDL for GraphQL).
• Generated client types for TypeScript / Dart / Kotlin.
• Set of automated tests covering all endpoints (unit + integration).
• Load tests (k6) and report (p50/p95/p99 latency, RPS).
• Documentation in Swagger UI / Redoc / GraphiQL.
• Team training (2–4 hour workshop).
• Support for 30 days after delivery (per contract).

Our experience

• 10+ years in the API development market.
• 200+ completed projects (REST, GraphQL, WebSocket, tRPC).
• 50+ certified engineers (AWS, Kubernetes, API Design).
• Traffic savings averaging 85% when migrating from REST to GraphQL for mobile apps.
• 100% backward compatibility — not a single broken client in the last 3 years.

Timeline

API development for a typical SaaS project with 30–50 endpoints: from 3 to 8 weeks depending on business logic complexity and number of external integrations. Migration of an existing REST API to GraphQL: from 2 to 6 weeks. Adding a WebSocket layer to an existing backend: from 1 to 3 weeks. Cost is calculated individually after an audit. Get a consultation — contact us to discuss your project.