---
title: "GraphQL | Skills We Assign For | Azendo"
description: "GraphQL where clients drive the query — what it solves, what it moves onto the server, and the Azendo roles assigned for it."
url: "https://azendo.co/skills/graphql/"
---

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

# GraphQL.

GraphQL is a query language for APIs that lets a client specify exactly which fields it needs in a single request. It targets a specific problem: clients either making many round trips or receiving far more data than they use.

## Where GraphQL fits on a long engagement.

GraphQL genuinely helps where many different clients need different shapes of the same data. A mobile app on a slow connection and a desktop dashboard can each request precisely what they render, without the API team shipping a new endpoint for every screen.

It moves difficulty rather than removing it. Caching is harder than with REST, a badly shaped query can be expensive to resolve, and query depth becomes something the server has to defend against. Those are solvable, but they are work that a REST API would not have required, and they need to be budgeted rather than discovered.

## What an assigned team does with GraphQL.

GraphQL concentrates decisions in the schema, and a schema edited by many hands over several years without one owner becomes a surface nobody can reason about. Deprecating a field requires knowing who queries it, and that knowledge is held by people rather than by tooling.

The performance work is continuous rather than one-off — resolver behaviour changes as data volume does. Where that becomes the binding constraint, it is usually assigned alongside [DevOps as a service](https://azendo.co/services/cloud-and-devops/) capacity watching the same system from the infrastructure side.

## What we use GraphQL for.

* Several clients, one data graph Web, mobile and partner surfaces each requesting what they need without a proliferation of bespoke endpoints.
* Reducing round trips on mobile One request replacing a sequence of dependent calls, which matters most on exactly the connections that are worst.
* A layer over several services One coherent graph in front of systems that were built separately and do not agree on naming.

## How GraphQL capacity is assigned.

GraphQL capacity is assigned under [software development outsourcing](https://azendo.co/services/software-development/). Whether it is the right choice at all is a question worth asking at scoping rather than after the schema exists.

## Roles we assign GraphQL 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/)
* [gRPC — skill we assign for](https://azendo.co/skills/grpc/)
* [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 GraphQL 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/)