---
title: "gRPC | Skills We Assign For | Azendo"
description: "gRPC for service-to-service calls — contract enforcement, streaming, and the Azendo roles assigned for backend and integration work."
url: "https://azendo.co/skills/grpc/"
---

[Skills](https://azendo.co/skills/) APIs and integration 

# gRPC.

gRPC is a remote procedure call framework using Protocol Buffers for serialisation and HTTP/2 for transport. It is used for internal service-to-service communication where efficiency and a strictly enforced contract matter more than being readable in a browser.

## Where gRPC fits on a long engagement.

The contract is the point. A .proto file defines the interface, generates client and server code in every language involved, and makes an incompatible change fail at build time rather than in production. For internal traffic between services owned by different teams, that is a stronger guarantee than documentation and good intentions.

It is a poor fit anywhere the caller is a browser or an external partner. Binary payloads are not inspectable with ordinary tools, browser support needs a proxy, and a partner integration in gRPC is a support burden you will feel. Most estates run gRPC internally and REST at the edge.

## What an assigned team does with gRPC.

Service-to-service contracts are where an assigned team's memory pays off directly. The proto files describe what the services agree to today; why a field was deprecated and what still depends on it lives with whoever was there. Rotating that person out converts a cheap change into a risky one.

gRPC work almost never stands alone. It arrives as part of a wider service architecture, assigned under [outsource software development services](https://azendo.co/services/software-development/), with the platform capacity to run it agreed at the same time.

## What we use gRPC for.

* High-volume internal traffic Service-to-service calls where payload size and latency are measured, and the saving over JSON is material.
* Contracts across team boundaries A generated interface two teams cannot accidentally break, enforced by the build rather than by review.
* Streaming between services Long-lived bidirectional connections where request and response is the wrong shape for the problem.

## How gRPC capacity is assigned.

gRPC work is assigned under outsource software development services, usually as part of a wider service architecture rather than as an isolated piece. The four steps from brief to first sprint are described in [four steps](https://azendo.co/how-it-works/).

## Roles we assign gRPC for

* [Integration Engineer AI automation engineering](https://azendo.co/services/ai-automation-engineering/integration-engineer/)
* [Backend Developer Software development](https://azendo.co/services/software-development/backend-developer/)

## Service lines it sits in

* [AI automation engineering](https://azendo.co/services/ai-automation-engineering/)
* [Software development](https://azendo.co/services/software-development/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in apis and integration

* [REST — skill we assign for](https://azendo.co/skills/rest/)
* [GraphQL — skill we assign for](https://azendo.co/skills/graphql/)
* [webhooks — skill we assign for](https://azendo.co/skills/webhooks/)
* [Kafka — skill we assign for](https://azendo.co/skills/kafka/)
* [API design — skill we assign for](https://azendo.co/skills/api-design/)
* [message queues — skill we assign for](https://azendo.co/skills/message-queues/)
* [FastAPI — skill we assign for](https://azendo.co/skills/fastapi/)
* [RabbitMQ — skill we assign for](https://azendo.co/skills/rabbitmq/)

## Tell us what your roadmap needs gRPC for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)