# When to Use gRPC — gRPC

Source: https://www.skillbyai.com/en/grpc/f-fit

> Strengths and limits.

## Service-to-service and streaming

gRPC is a strong fit for **internal microservice communication**, polyglot systems that need a strict contract, low-latency and high-throughput calls, **streaming** (telemetry, chat, live updates), and mobile clients where bandwidth matters. It is less convenient for browsers (which cannot speak native gRPC directly), for public APIs that developers explore with curl, and where HTTP caching is important. Many organisations use gRPC internally and expose REST or GraphQL at the edge.

## Comparing API styles

Typical choices.

```text
                    REST/JSON          GraphQL              gRPC
payload             text JSON          text JSON            binary protobuf
contract            optional OpenAPI   required schema      required .proto
streaming           limited (SSE)      subscriptions        built in, both directions
browser support     native             native               via gRPC-Web / Connect / gateway
best at             public APIs        client-shaped reads  internal service calls
```

## Expose REST at the edge if needed

A gateway can translate REST/JSON to gRPC so external clients do not need gRPC tooling.

**Quiz:** Which scenario suits gRPC best?

- [ ] Browser forms without any gateway
- [ ] A public API explored with curl by thousands of developers
- [ ] Serving static images via a CDN
- [x] High-throughput calls between internal microservices

*Answer:* High-throughput calls between internal microservices. Internal, typed, efficient.