4. Как схема связана с кодом
SDL — декларация.
Сервер должен сопоставить поля типам данных и резолверам.
Java (graphql-java, Spring for GraphQL)
SDL:
Резолвер:
GraphQL автоматически соединяет:
поле user → метод user класса UserResolver
аргумент id → параметр метода
На что важно смотреть в связке схема - код
SDL описывает только форму данных, не логику.
Все поля объектных типов должны иметь резолверы (кроме простых полей, которые GraphQL просто читает из объекта).
input использует DTO-классы.
enum маппится на Enum-класс.
union и interface требуют регистрации type resolver-а.
5. Эволюция схемы: изменение и поддержка версий
GraphQL спроектирован так, чтобы обеспечивать обратную совместимость.
Важный принцип: старые клиенты должны продолжать работать после обновлений.
1. Добавление полей — безопасная операция
Можно безболезненно добавлять:
новые поля в типы
новые аргументы с default value
новые типы
новые enum-значения (если клиенты готовы к неизвестным значениям)
Пример:
2. Деприкация полей
Поле нельзя удалить сразу — сначала его помечают как @deprecated.
Клиентский код и инструменты разработчика (GraphiQL, GraphQL Codegen) предупредят о деприкации.
3. Удаление полей
Удалять поле можно только после:
уведомления клиентов,
завершения миграции SDK/фронта,
истечения grace-period'a.
4. Эволюция enum-ов
Добавлять значения — безопасно.
Удалять — нет.
5. Миграции input-типов
Если нужно изменить входные данные:
#Java #middle #GraphQL
SDL — декларация.
Сервер должен сопоставить поля типам данных и резолверам.
Java (graphql-java, Spring for GraphQL)
SDL:
type Query {
user(id: ID!): User
}Резолвер:
@Component
public class UserResolver implements GraphQLQueryResolver {
private final UserService service;
public UserResolver(UserService service) {
this.service = service;
}
public User user(Long id) {
return service.findById(id);
}
}
GraphQL автоматически соединяет:
поле user → метод user класса UserResolver
аргумент id → параметр метода
На что важно смотреть в связке схема - код
SDL описывает только форму данных, не логику.
Все поля объектных типов должны иметь резолверы (кроме простых полей, которые GraphQL просто читает из объекта).
input использует DTO-классы.
enum маппится на Enum-класс.
union и interface требуют регистрации type resolver-а.
5. Эволюция схемы: изменение и поддержка версий
GraphQL спроектирован так, чтобы обеспечивать обратную совместимость.
Важный принцип: старые клиенты должны продолжать работать после обновлений.
1. Добавление полей — безопасная операция
Можно безболезненно добавлять:
новые поля в типы
новые аргументы с default value
новые типы
новые enum-значения (если клиенты готовы к неизвестным значениям)
Пример:
type User {
id: ID!
name: String!
email: String # новое поле
}2. Деприкация полей
Поле нельзя удалить сразу — сначала его помечают как @deprecated.
type User {
id: ID!
name: String!
# старое поле
username: String @deprecated(reason: "Use 'name' instead")
}Клиентский код и инструменты разработчика (GraphiQL, GraphQL Codegen) предупредят о деприкации.
3. Удаление полей
Удалять поле можно только после:
уведомления клиентов,
завершения миграции SDK/фронта,
истечения grace-period'a.
4. Эволюция enum-ов
Добавлять значения — безопасно.
Удалять — нет.
5. Миграции input-типов
Если нужно изменить входные данные:
Старое:
input CreatePostInput {
title: String!
}
Новое:
input CreatePostInput {
title: String!
content: String @deprecated(reason: "Use body instead")
body: String
}
#Java #middle #GraphQL
👍2
Запросы и мутации в GraphQL
GraphQL опирается на две основные операции:
Query — безопасные операции чтения данных.
Mutation — операции изменения состояния (создание, обновление, удаление).
Обе операции используют один и тот же язык запросов, отличаются только семантикой:
Query не влияет на состояние системы, Mutation — влияет.
1. Как выглядит запрос (Query)
GraphQL-запрос — декларативное описание структуры данных, которую клиент хочет получить.
Простой пример:
Здесь:
query — тип операции (можно опустить: GraphQL сам определит, что это запрос).
user(id: 42) — вызов поля корневого типа Query.
{ name, avatar } — конкретные поля, которые клиент хочет получить.
GraphQL не вернёт дополнительные поля и не допустит отсутствующих — запрос полностью определяет форму ответа.
Ответ будет ровно такой:
2. Как работает передача аргументов
Аргументы передаются в круглых скобках и могут быть любого типа, определённого в схеме:
скаляры, enum, input-объекты.
Пример схемы:
Пример запроса:
Ответ будет:
2.1. Переменные запроса (не хардкодим аргументы)
GraphQL поддерживает variables, что особенно важно для фронтенда.
Запрос:
Передаваемые переменные:
Сервер объединяет запрос с переменными и выполняет его.
Преимущества переменных:
запрос можно кэшировать,
тело операции не меняется,
безопаснее, чем вставлять значения в строку.
3. Что делает Mutation
Mutation изменяет данные.
Пример схемы:
Пример запроса:
Mutation возвращает объект результата, содержащий новое состояние или подтверждение.
Ответ:
Важный принцип:
Mutation считается одиночной транзакцией.
Даже если внутри происходит много действий, GraphQL гарантирует их упорядоченное выполнение.
4. Возврат данных в нужной форме
GraphQL всегда возвращает данные:
в структуре, которую запросил клиент
в иерархии, описанной в запросе
строго тех типов, которые указаны в схеме
Пример: вложенная выборка.
Ответ:
#Java #middle #GraphQL #Query #Mutation
GraphQL опирается на две основные операции:
Query — безопасные операции чтения данных.
Mutation — операции изменения состояния (создание, обновление, удаление).
Обе операции используют один и тот же язык запросов, отличаются только семантикой:
Query не влияет на состояние системы, Mutation — влияет.
1. Как выглядит запрос (Query)
GraphQL-запрос — декларативное описание структуры данных, которую клиент хочет получить.
Простой пример:
query {
user(id: 42) {
name
avatar
}
}Здесь:
query — тип операции (можно опустить: GraphQL сам определит, что это запрос).
user(id: 42) — вызов поля корневого типа Query.
{ name, avatar } — конкретные поля, которые клиент хочет получить.
GraphQL не вернёт дополнительные поля и не допустит отсутствующих — запрос полностью определяет форму ответа.
Ответ будет ровно такой:
{
"data": {
"user": {
"name": "Den",
"avatar": "https://example.com/den.png"
}
}
}
Никаких “лишних” полей.2. Как работает передача аргументов
Аргументы передаются в круглых скобках и могут быть любого типа, определённого в схеме:
скаляры, enum, input-объекты.
Пример схемы:
type Query {
posts(limit: Int, authorId: ID): [Post!]!
}Пример запроса:
query {
posts(limit: 5, authorId: 42) {
id
title
}
}Ответ будет:
{
"data": {
"posts": [
{ "id": "101", "title": "GraphQL SDL" },
{ "id": "102", "title": "gRPC vs GraphQL" }
]
}
}2.1. Переменные запроса (не хардкодим аргументы)
GraphQL поддерживает variables, что особенно важно для фронтенда.
Запрос:
query GetUser($id: ID!) {
user(id: $id) {
name
avatar
}
}Передаваемые переменные:
{
"id": 42
}Сервер объединяет запрос с переменными и выполняет его.
Преимущества переменных:
запрос можно кэшировать,
тело операции не меняется,
безопаснее, чем вставлять значения в строку.
3. Что делает Mutation
Mutation изменяет данные.
Пример схемы:
type Mutation {
createPost(input: CreatePostInput!): Post!
}Пример запроса:
mutation {
createPost(input: { title: "GraphQL", content: "SDL explained" }) {
id
title
}
}Mutation возвращает объект результата, содержащий новое состояние или подтверждение.
Ответ:
{
"data": {
"createPost": {
"id": "501",
"title": "GraphQL"
}
}
}Важный принцип:
Mutation считается одиночной транзакцией.
Даже если внутри происходит много действий, GraphQL гарантирует их упорядоченное выполнение.
4. Возврат данных в нужной форме
GraphQL всегда возвращает данные:
в структуре, которую запросил клиент
в иерархии, описанной в запросе
строго тех типов, которые указаны в схеме
Пример: вложенная выборка.
query {
user(id: 1) {
name
posts(limit: 2) {
title
comments {
text
}
}
}
}Ответ:
{
"data": {
"user": {
"name": "Den",
"posts": [
{
"title": "GraphQL Basics",
"comments": [
{ "text": "Отличная статья" }
]
},
{
"title": "SDL Tutorial",
"comments": []
}
]
}
}
}
Сервер не может изменить структуру ответа — она определяется клиентом.#Java #middle #GraphQL #Query #Mutation
👍2
5. Ошибки и partial responses
GraphQL всегда возвращает JSON-объект с двумя ключами:
Что важно:
GraphQL может вернуть часть данных, даже если произошла ошибка.
пример: запрос
допустим, поле posts упало из-за ошибки в БД.
Ответ:
GraphQL:
не останавливает выполнение всего запроса,
возвращает то, что смог,
указывает путь к проблемному полю.
Это концепция partial response, которой нет ни в REST, ни в gRPC.
6. Как Mutation обрабатывает ошибки
Mutation также может вернуть частичный результат, но чаще ошибка означает, что произошло отклонение операции:
GraphQL намеренно не использует коды HTTP-статуса, кроме:
200 — запрос обработан
400 — синтаксическая ошибка запроса
500 — ошибка самого сервера GraphQL (не бизнес-ошибка)
#Java #middle #GraphQL #Query #Mutation
GraphQL всегда возвращает JSON-объект с двумя ключами:
data
errors
Что важно:
GraphQL может вернуть часть данных, даже если произошла ошибка.
пример: запрос
query {
user(id: 1) {
name
posts {
title
likes
}
}
}допустим, поле posts упало из-за ошибки в БД.
Ответ:
{
"data": {
"user": {
"name": "Den",
"posts": null
}
},
"errors": [
{
"message": "Database timeout",
"path": ["user", "posts"]
}
]
}GraphQL:
не останавливает выполнение всего запроса,
возвращает то, что смог,
указывает путь к проблемному полю.
Это концепция partial response, которой нет ни в REST, ни в gRPC.
6. Как Mutation обрабатывает ошибки
Mutation также может вернуть частичный результат, но чаще ошибка означает, что произошло отклонение операции:
{
"data": {
"createPost": null
},
"errors": [
{
"message": "User not authorized",
"path": ["createPost"]
}
]
}GraphQL намеренно не использует коды HTTP-статуса, кроме:
200 — запрос обработан
400 — синтаксическая ошибка запроса
500 — ошибка самого сервера GraphQL (не бизнес-ошибка)
#Java #middle #GraphQL #Query #Mutation
👍1
Фрагменты, директивы и переменные
GraphQL — декларативный язык, но его мощь раскрывается по-настоящему, когда вы начинаете использовать фрагменты, директивы и переменные.
Эти инструменты позволяют:
избегать дублирования запросов,
включать или исключать поля динамически,
передавать аргументы безопасно,
строить сложные запросы, сохраняя читаемость.
1. Фрагменты
Фрагмент (fragment) — это именованный блок запроса, который описывает набор полей.
Он позволяет вынести общую часть и использовать её в нескольких местах.
Главная цель: избежать повторов полей.
Пример без фрагментов:
Версия с фрагментом
Как работает фрагмент
fragment UserBasic on User — объявление фрагмента.
User — тип, которому фрагмент принадлежит.
...UserBasic — вставка фрагмента.
Фрагменты можно вкладывать друг в друга и использовать с union и interface.
Кейсы, где фрагменты обязательны
Одинаковая структура данных в нескольких частях UI
Профили пользователей, карточки, списки.
Сложные запросы с глубокой вложенностью
Общие части выносятся в фрагменты.
Работа с interface и union
Позволяют описывать поля для нескольких типов.
Крупные запросы с десятками полей
Легче читать, тестировать и поддерживать.
2. Директивы
Директивы — это аннотации, которые модифицируют выполнение запроса.
Они влияют на структуру данных, которые вернёт сервер.
GraphQL имеет встроенные директивы и позволяет создавать свои.
2.1 Директива @include
Поле будет включено только если условие истинно.
2.2 Директива @skip
Обратная логика:
2.3 Директива @deprecated
Помечает поле устаревшим.
2.4 Кастомные директивы
Пример (схема):
Резолвер может модифицировать строку на лету (например, вернуть верхний регистр).
Это используется для логирования, авторизации, кеширования, маскирования данных.
3. Переменные в запросах
Переменные — это место, где GraphQL становится особенно полезным.
Они позволяют использовать один и тот же запрос с разными параметрами, не переписывая запрос.
3.1 Базовый пример
Запрос:
Переменные:
Сервер соединяет тело запроса и переменные и выполняет.
3.2 Переменные для input-объектов (в мутациях)
Мутация:
Переменные:
Это безопаснее, чем писать input прямо в теле мутации.
3.3 Комбинирование переменных с директивами
Комбинация:
один запрос,
два режима вывода данных,
ноль дублирования.
#Java #middle #GraphQL #Query
GraphQL — декларативный язык, но его мощь раскрывается по-настоящему, когда вы начинаете использовать фрагменты, директивы и переменные.
Эти инструменты позволяют:
избегать дублирования запросов,
включать или исключать поля динамически,
передавать аргументы безопасно,
строить сложные запросы, сохраняя читаемость.
1. Фрагменты
Фрагмент (fragment) — это именованный блок запроса, который описывает набор полей.
Он позволяет вынести общую часть и использовать её в нескольких местах.
Главная цель: избежать повторов полей.
Пример без фрагментов:
query {
user(id: 1) {
id
name
avatar
}
post(id: 10) {
author {
id
name
avatar
}
}
}
Повторяются три поля id, name, avatar.Версия с фрагментом
fragment UserBasic on User {
id
name
avatar
}
query {
user(id: 1) {
...UserBasic
}
post(id: 10) {
author {
...UserBasic
}
}
}
Теперь изменения структуры (например, добавление role) делаются в одном месте — фрагменте.Как работает фрагмент
fragment UserBasic on User — объявление фрагмента.
User — тип, которому фрагмент принадлежит.
...UserBasic — вставка фрагмента.
Фрагменты можно вкладывать друг в друга и использовать с union и interface.
Кейсы, где фрагменты обязательны
Одинаковая структура данных в нескольких частях UI
Профили пользователей, карточки, списки.
Сложные запросы с глубокой вложенностью
Общие части выносятся в фрагменты.
Работа с interface и union
Позволяют описывать поля для нескольких типов.
Крупные запросы с десятками полей
Легче читать, тестировать и поддерживать.
2. Директивы
Директивы — это аннотации, которые модифицируют выполнение запроса.
Они влияют на структуру данных, которые вернёт сервер.
GraphQL имеет встроенные директивы и позволяет создавать свои.
2.1 Директива @include
Поле будет включено только если условие истинно.
query GetUser($showAvatar: Boolean!) {
user(id: 1) {
name
avatar @include(if: $showAvatar)
}
}
Переменные:
{ "showAvatar": true }
Если showAvatar = false, поле avatar пропадёт из ответа целиком.2.2 Директива @skip
Обратная логика:
avatar @skip(if: $binaryMode)
Если binaryMode = true, поле будет пропущено.
2.3 Директива @deprecated
Помечает поле устаревшим.
type User {
username: String @deprecated(reason: "Use 'name' instead")
}
Эта директива влияет на документацию и IDE, но не на данные.2.4 Кастомные директивы
Пример (схема):
directive @upper on FIELD_DEFINITION
Резолвер может модифицировать строку на лету (например, вернуть верхний регистр).
Это используется для логирования, авторизации, кеширования, маскирования данных.
3. Переменные в запросах
Переменные — это место, где GraphQL становится особенно полезным.
Они позволяют использовать один и тот же запрос с разными параметрами, не переписывая запрос.
3.1 Базовый пример
Запрос:
query GetPost($id: ID!) {
post(id: $id) {
title
content
}
}Переменные:
{
"id": 100
}Сервер соединяет тело запроса и переменные и выполняет.
3.2 Переменные для input-объектов (в мутациях)
Мутация:
mutation CreatePost($input: CreatePostInput!) {
createPost(input: $input) {
id
title
}
}Переменные:
{
"input": {
"title": "GraphQL",
"content": "Powerful queries"
}
}Это безопаснее, чем писать input прямо в теле мутации.
3.3 Комбинирование переменных с директивами
query User(
$id: ID!,
$withPosts: Boolean!
) {
user(id: $id) {
name
posts @include(if: $withPosts) {
title
}
}
}
Комбинация:
один запрос,
два режима вывода данных,
ноль дублирования.
#Java #middle #GraphQL #Query
👍2
4. Реальные производственные кейсы
Кейc 1: мобильная и web-версия используют разные наборы полей
Мобильный клиент получает минимум данных.
Web — максимум.
Кейc 2: переиспользование структуры пользователя
Все блоки страницы используют одну структуру.
CRM-интерфейсы любят такое.
Кейc 3: миграции схемы через директивы
Старая модель:
Frontend получает предупреждение в IDE — никаких тайных поломок.
Кейc 4: сложные фильтры в одном запросе
Переменные:
#Java #middle #GraphQL #Query
Кейc 1: мобильная и web-версия используют разные наборы полей
query User(
$id: ID!,
$isMobile: Boolean!
) {
user(id: $id) {
name
avatar @skip(if: $isMobile)
posts @include(if: $isMobile) {
title
}
}
}
Мобильный клиент получает минимум данных.
Web — максимум.
Кейc 2: переиспользование структуры пользователя
fragment UserCard on User {
id
name
avatar
}
query PageData {
recommendedUsers { ...UserCard }
recentVisitors { ...UserCard }
followers { ...UserCard }
}Все блоки страницы используют одну структуру.
CRM-интерфейсы любят такое.
Кейc 3: миграции схемы через директивы
Старая модель:
username @deprecated(reason: "Use 'login' instead")
Frontend получает предупреждение в IDE — никаких тайных поломок.
Кейc 4: сложные фильтры в одном запросе
query FilterPosts($filter: PostFilter!) {
posts(filter: $filter) {
id
title
}
}Переменные:
{
"filter": {
"authorId": 1,
"tags": ["graphql", "java"],
"minLikes": 10
}
}#Java #middle #GraphQL #Query
👍2
Реализация GraphQL на сервере
1. Как сервер “понимает” запросы
GraphQL — это не просто формат данных. Это полноценный язык запросов, который сервер интерпретирует строжайшим образом.
На сервере присутствуют три ключевых компонента:
Схема (Schema) — декларативное описание типов, запросов, мутаций и подписок.
Исполнитель (Executor) — механизм, который умеет разбирать, валидировать и выполнять запросы.
Резолверы (resolvers) — функции, которые реально достают данные.
Процесс обработки запроса выглядит так:
Шаг 1. Парсинг
Запрос, полученный в виде строки, разбирается в AST (абстрактное синтаксическое дерево).
GraphQL понимает только корректный язык запросов, поэтому на этом этапе запрос может быть отклонён.
Шаг 2. Валидация
AST сравнивается со схемой.
Сервер проверяет:
существуют ли указанные поля;
правильно ли переданы аргументы;
корректны ли типы;
не запрошены ли деприкейтнутые или отсутствующие типы.
Если запрос не соответствует схеме, сервер вообще не перейдёт к резолверам.
Шаг 3. Выполнение
GraphQL выполняет запрос сверху вниз, проходя по полям и вызывая резолверы там, где они определены.
GraphQL никогда не “догадывается”, где лежат данные.
Он лишь исполняет дерево запроса, вызывая привязанные функции.
2. Роль резолверов (resolvers)
Резолвер — это функция, которая отвечает на вопрос:
“Как получить данные для этого конкретного поля?”
В GraphQL у каждого поля может быть свой резолвер, хотя обычно определяют резолверы для корневых типов: Query, Mutation, Subscription.
Резолвер принимает три основных аргумента:
parent — результат предыдущего резолвера (нужен для вложенных структур);
args — аргументы, которые указал клиент;
context — общий контекст запроса (авторизация, транзакция, соединения с БД).
Пример простого резолвера на Java (Spring Boot + graphql-java-tools):
Резолвер выполняет ровно одну задачу: достать данные.
GraphQL не хранит состояние, не кэширует данные, не соединяется с БД — всё это делает твой код через резолверы.
3. Маппинг схемы на реальные источники данных
GraphQL — это уровень между клиентом и данными.
Источники могут быть любыми:
реляционная БД (PostgreSQL);
документоориентированная БД (MongoDB);
REST API других микросервисов;
gRPC сервисы;
сообщения из Kafka;
кэш Redis.
GraphQL не диктует, где должны лежать данные. Он просто обеспечивает единый интерфейс запросов.
Пример маппинга:
Резолверы:
Отсюда следует ключевой принцип:
сервер выполняет только то, что клиент запросил — ни больше, ни меньше.
#Java #middle #GraphQL
1. Как сервер “понимает” запросы
GraphQL — это не просто формат данных. Это полноценный язык запросов, который сервер интерпретирует строжайшим образом.
На сервере присутствуют три ключевых компонента:
Схема (Schema) — декларативное описание типов, запросов, мутаций и подписок.
Исполнитель (Executor) — механизм, который умеет разбирать, валидировать и выполнять запросы.
Резолверы (resolvers) — функции, которые реально достают данные.
Процесс обработки запроса выглядит так:
Шаг 1. Парсинг
Запрос, полученный в виде строки, разбирается в AST (абстрактное синтаксическое дерево).
GraphQL понимает только корректный язык запросов, поэтому на этом этапе запрос может быть отклонён.
Шаг 2. Валидация
AST сравнивается со схемой.
Сервер проверяет:
существуют ли указанные поля;
правильно ли переданы аргументы;
корректны ли типы;
не запрошены ли деприкейтнутые или отсутствующие типы.
Если запрос не соответствует схеме, сервер вообще не перейдёт к резолверам.
Шаг 3. Выполнение
GraphQL выполняет запрос сверху вниз, проходя по полям и вызывая резолверы там, где они определены.
GraphQL никогда не “догадывается”, где лежат данные.
Он лишь исполняет дерево запроса, вызывая привязанные функции.
2. Роль резолверов (resolvers)
Резолвер — это функция, которая отвечает на вопрос:
“Как получить данные для этого конкретного поля?”
В GraphQL у каждого поля может быть свой резолвер, хотя обычно определяют резолверы для корневых типов: Query, Mutation, Subscription.
Резолвер принимает три основных аргумента:
parent — результат предыдущего резолвера (нужен для вложенных структур);
args — аргументы, которые указал клиент;
context — общий контекст запроса (авторизация, транзакция, соединения с БД).
Пример простого резолвера на Java (Spring Boot + graphql-java-tools):
@Component
public class UserQueryResolver implements GraphQLQueryResolver {
private final UserService service;
public UserQueryResolver(UserService service) {
this.service = service;
}
public User userById(Long id) {
return service.findById(id);
}
}
Резолвер выполняет ровно одну задачу: достать данные.
GraphQL не хранит состояние, не кэширует данные, не соединяется с БД — всё это делает твой код через резолверы.
3. Маппинг схемы на реальные источники данных
GraphQL — это уровень между клиентом и данными.
Источники могут быть любыми:
реляционная БД (PostgreSQL);
документоориентированная БД (MongoDB);
REST API других микросервисов;
gRPC сервисы;
сообщения из Kafka;
кэш Redis.
GraphQL не диктует, где должны лежать данные. Он просто обеспечивает единый интерфейс запросов.
Пример маппинга:
type Query {
user(id: ID!): User
}
type User {
id: ID!
name: String!
posts: [Post!]!
}Резолверы:
@Component
public class UserResolver implements GraphQLResolver<User> {
private final PostService postService;
public UserResolver(PostService postService) {
this.postService = postService;
}
public List<Post> posts(User user) {
return postService.findByUserId(user.getId());
}
}
GraphQL вызывает posts() только если клиент запросит поле posts.
Если клиент запросит только user { id name }, резолвер posts не будет вызван вообще.
Отсюда следует ключевой принцип:
сервер выполняет только то, что клиент запросил — ни больше, ни меньше.
#Java #middle #GraphQL
👍1
4. Типичная архитектура GraphQL-сервера (Spring Boot)
Структура проекта в Java обычно такая:
Описание этапов:
Схема
Файл .graphqls описывает типы и операции.
Резолверы
Связывают поля схемы с Java-методами.
Сервисы
Логика бизнес-операций.
Репозитории
SQL/NoSQL/REST/gRPC слой, через который сервер реально получает данные.
Context
Сюда кладут:
JWT токен
объект пользователя
транзакции
общие ресурсы
5. Пример полного цикла запроса
Клиент отправляет запрос:
Что делает сервер:
Парсит запрос → AST
Проверяет типы по схеме
Вызывает QueryResolver.user(id=10)
Получает объект User
Чтобы отдать поле posts, вызывает UserResolver.posts(user)
Формирует объект ответа, возвращает клиенту JSON
Клиент всегда получает именно ту форму данных, которую указал.
Сервер не отдаёт лишних полей.
6. Почему GraphQL — это слой поверх данных, а не база данных
GraphQL:
не знает SQL;
не оптимизирует запросы;
не управляет транзакциями;
не индексирует данные;
не проверяет связи между таблицами.
GraphQL — это универсальный контракт между клиентом и сервером, а не способ хранения данных.
Он лишь обеспечивает:
строгую структуру данных (схему)
гибкие запросы от клиента
единый интерфейс ко множеству источников
оптимизацию на уровне поля (через резолверы)
Всё остальное — на стороне backend-логики.
#Java #middle #GraphQL
Структура проекта в Java обычно такая:
/graphql
/schema
schema.graphqls
/resolvers
QueryResolver.java
MutationResolver.java
UserResolver.java
PostResolver.java
/services
UserService.java
PostService.java
/repositories
UserRepository.java
PostRepository.java
Описание этапов:
Схема
Файл .graphqls описывает типы и операции.
Резолверы
Связывают поля схемы с Java-методами.
Сервисы
Логика бизнес-операций.
Репозитории
SQL/NoSQL/REST/gRPC слой, через который сервер реально получает данные.
Context
Сюда кладут:
JWT токен
объект пользователя
транзакции
общие ресурсы
5. Пример полного цикла запроса
Клиент отправляет запрос:
query {
user(id: 10) {
id
name
posts {
id
title
}
}
}Что делает сервер:
Парсит запрос → AST
Проверяет типы по схеме
Вызывает QueryResolver.user(id=10)
Получает объект User
Чтобы отдать поле posts, вызывает UserResolver.posts(user)
Формирует объект ответа, возвращает клиенту JSON
Клиент всегда получает именно ту форму данных, которую указал.
Сервер не отдаёт лишних полей.
6. Почему GraphQL — это слой поверх данных, а не база данных
GraphQL:
не знает SQL;
не оптимизирует запросы;
не управляет транзакциями;
не индексирует данные;
не проверяет связи между таблицами.
GraphQL — это универсальный контракт между клиентом и сервером, а не способ хранения данных.
Он лишь обеспечивает:
строгую структуру данных (схему)
гибкие запросы от клиента
единый интерфейс ко множеству источников
оптимизацию на уровне поля (через резолверы)
Всё остальное — на стороне backend-логики.
#Java #middle #GraphQL
👍3
GraphQL vs REST vs gRPC
REST — ресурсно-ориентированный HTTP API, обычно JSON по HTTP/1.1. Прост, совместим с любым клиентом, хорош для публичных и простых API.
GraphQL — язык запросов + схема; клиент сам описывает форму данных. Один эндпоинт, строгая схема, гибкость запросов, удобен для фронтенда.
gRPC — RPC-фреймворк на основе HTTP/2 + Protocol Buffers; строгие контракты (.proto), бинарная сериализация, встроенный стриминг. Ориентирован на высокую производительность и внутренние сервисы.
Формат данных
REST → JSON (текстовый, человекочитаемый).
GraphQL → JSON-ответ, но запросы декларативны и строго типизированы схемой.
gRPC → Protocol Buffers (бинарный), компактно, фиксированные поля.
Вывод: protobuf обычно экономит трафик и парсится быстрее; JSON удобнее для дебага и совместимости.
Протокол транспорта
REST → HTTP/1.1 (обычно), можно HTTP/2, но без нативного стриминга.
GraphQL → обычно HTTP/1.1 POST/GET для Query/Mutation; Subscription — WebSocket или HTTP/2 SSE.
gRPC → HTTP/2 по умолчанию, мультиплексирование, потоковые фреймы, двунаправленность.
Вывод: для потоковых сценариев и мультиплексирования gRPC технически лучше.
Типы взаимодействия
REST → запрос/ответ (stateless).
GraphQL → query/mutation/subscription; один запрос может агрегировать много сущностей.
gRPC → unary, server streaming, client streaming, bidirectional streaming (всё на уровне протокола).
Вывод: если нужны сложные стримы и двунаправленные каналы — gRPC.
Типизация и контракт
REST → схема часто нестрогая (OpenAPI/Swagger добавляет контракт).
GraphQL → строгая схема (SDL).
gRPC → строгие контракты (.proto).
Вывод: GraphQL и gRPC обеспечивают статический контракт; REST требует дополнительных инструментов для той же дисциплины.
Производительность (в общих чертах)
gRPC обычно выигрывает по пропускной способности и латентности за счёт бинарной сериализации и HTTP/2.
GraphQL может быть эффективным по числу запросов (агрегация) и по уменьшению round-trip’ов, но JSON+резолверы добавляют накладные расходы.
REST проще и зачастую медленнее при больших объёмах и при множественных запросах с агрегацией.
Вывод: для внутренней коммуникации между сервисами с высокой нагрузкой — gRPC; для клиентского слоя — GraphQL/REST в зависимости от потребностей.
Эволюция API и версияция
REST → часто версионируют (/v1/) или добавляют параметры; ломкость при изменениях.
GraphQL → расширяемость без версий (добавление полей безопасно), депрекация поддерживается.
gRPC → совместимость через правила protobuf (резервирование, добавление новых полей безопасно при соблюдении правил).
Вывод: GraphQL и gRPC дают удобные инструменты для эволюции без жесткой версии.
Инструментальная поддержка и экосистема
REST → универсальная поддержка, простые средства тестирования.
GraphQL → богатая экосистема: GraphiQL, Apollo, Relay, Codegen. Отлично для фронтенда.
gRPC → генерация стубов под любые языки, хорошие SDK для серверов и клиентов; браузерная поддержка требует gRPC-Web.
Вывод: выбор зависит от клиентской среды: браузер напрямую лучше работает с REST/GraphQL; для gRPC нужен шлюз (gRPC-Web) или прокси.
#Java #middle #GraphQL
REST — ресурсно-ориентированный HTTP API, обычно JSON по HTTP/1.1. Прост, совместим с любым клиентом, хорош для публичных и простых API.
GraphQL — язык запросов + схема; клиент сам описывает форму данных. Один эндпоинт, строгая схема, гибкость запросов, удобен для фронтенда.
gRPC — RPC-фреймворк на основе HTTP/2 + Protocol Buffers; строгие контракты (.proto), бинарная сериализация, встроенный стриминг. Ориентирован на высокую производительность и внутренние сервисы.
Формат данных
REST → JSON (текстовый, человекочитаемый).
GraphQL → JSON-ответ, но запросы декларативны и строго типизированы схемой.
gRPC → Protocol Buffers (бинарный), компактно, фиксированные поля.
Вывод: protobuf обычно экономит трафик и парсится быстрее; JSON удобнее для дебага и совместимости.
Протокол транспорта
REST → HTTP/1.1 (обычно), можно HTTP/2, но без нативного стриминга.
GraphQL → обычно HTTP/1.1 POST/GET для Query/Mutation; Subscription — WebSocket или HTTP/2 SSE.
gRPC → HTTP/2 по умолчанию, мультиплексирование, потоковые фреймы, двунаправленность.
Вывод: для потоковых сценариев и мультиплексирования gRPC технически лучше.
Типы взаимодействия
REST → запрос/ответ (stateless).
GraphQL → query/mutation/subscription; один запрос может агрегировать много сущностей.
gRPC → unary, server streaming, client streaming, bidirectional streaming (всё на уровне протокола).
Вывод: если нужны сложные стримы и двунаправленные каналы — gRPC.
Типизация и контракт
REST → схема часто нестрогая (OpenAPI/Swagger добавляет контракт).
GraphQL → строгая схема (SDL).
gRPC → строгие контракты (.proto).
Вывод: GraphQL и gRPC обеспечивают статический контракт; REST требует дополнительных инструментов для той же дисциплины.
Производительность (в общих чертах)
gRPC обычно выигрывает по пропускной способности и латентности за счёт бинарной сериализации и HTTP/2.
GraphQL может быть эффективным по числу запросов (агрегация) и по уменьшению round-trip’ов, но JSON+резолверы добавляют накладные расходы.
REST проще и зачастую медленнее при больших объёмах и при множественных запросах с агрегацией.
Вывод: для внутренней коммуникации между сервисами с высокой нагрузкой — gRPC; для клиентского слоя — GraphQL/REST в зависимости от потребностей.
Эволюция API и версияция
REST → часто версионируют (/v1/) или добавляют параметры; ломкость при изменениях.
GraphQL → расширяемость без версий (добавление полей безопасно), депрекация поддерживается.
gRPC → совместимость через правила protobuf (резервирование, добавление новых полей безопасно при соблюдении правил).
Вывод: GraphQL и gRPC дают удобные инструменты для эволюции без жесткой версии.
Инструментальная поддержка и экосистема
REST → универсальная поддержка, простые средства тестирования.
GraphQL → богатая экосистема: GraphiQL, Apollo, Relay, Codegen. Отлично для фронтенда.
gRPC → генерация стубов под любые языки, хорошие SDK для серверов и клиентов; браузерная поддержка требует gRPC-Web.
Вывод: выбор зависит от клиентской среды: браузер напрямую лучше работает с REST/GraphQL; для gRPC нужен шлюз (gRPC-Web) или прокси.
#Java #middle #GraphQL
👍1
Практические сценарии
публичный HTTP API для сторонних клиентов (публичная документация)
Выбор: REST или GraphQL
Почему: совместимость, простота, отсутствие необходимости требованиям к бинарному протоколу.
REST, если API простое, CRUD-ориентированное, нужно кэширование по URL и широчайшая совместимость.
GraphQL, если клиенты (много разных) требуют разные наборы данных и важно уменьшить число запросов.
фронтенд (SPA, мобильные клиенты) с разнообразными представлениями
Выбор: GraphQL
Почему: клиент сам формирует shape ответов; экономия round-trips; отличная интеграция с Apollo/Relay; кодогенерация типов для TS/Swift/Kotlin.
внутренняя связь между микросервисами с высокой нагрузкой
Выбор: gRPC
Почему: низкая латентность, компактность, стриминг, строгие контракты, удобная кодогенерация для множества языков.
real-time (чат, телеметрия, видео/аудио)
Выбор: gRPC (bidirectional) или GraphQL Subscriptions (WebSocket)
Почему: gRPC даёт нативный поток; GraphQL Subscriptions удобны для фронтенда, но требуют инфраструктуры и могут быть сложнее в масштабировании.
интеграция с legacy REST-сервисами
Выбор: GraphQL в качестве BFF (Backend-for-Frontend) или REST-шлюз
Почему: GraphQL может агрегировать несколько REST-вызовов и отдать клиенту нужную структуру.
Почему часто комбинируют: GraphQL для клиентов, gRPC для микросервисов
Это распространённый и рациональный паттерн:
Внутренние сервисы общаются по gRPC (эффективно, типобезопасно, стриминг).
BFF / API Gateway (или отдельный GraphQL-сервер) агрегирует данные из gRPC/REST/БД и предоставляет фронту единый, гибкий интерфейс.
Фронтенд работает с GraphQL (или REST), не заботясь о том, как именно данные доставлены внутри инфраструктуры.
Преимущества паттерна:
Отделение оптимизации внутренней сетевой коммуникации (gRPC) от удобства клиентских API (GraphQL).
Централизация логики агрегации и адаптации под клиентов.
Возможность менять внутреннюю реализацию без ломки фронта.
Пример (псевдокод Java resolver, вызывающий gRPC-stub):
Детальный разбор преимуществ и ограничений
Удобство разработки
REST: быстро стартовать, понятная модель. Но при сложных клиентских потребностях растёт число эндпоинтов.
GraphQL: позволяет фронтенду быстро изменять данные без координации с бэком, но требует работы со схемой и авторизацией на уровне полей.
gRPC: требует .proto и генерации стабов, но даёт сильную типизацию и меньше рутинного кода при изменениях.
Кеширование
REST: простое кеширование по URL (HTTP caches, CDNs).
GraphQL: кеширование сложнее — операция может возвращать разные поля; решения: persisted queries, apollo cache, CDN на уровне persisted queries/operation id.
gRPC: кеширование на транспортном уровне сложнее; обычно кешируют ответы в сервисах.
Отладка и наблюдаемость
REST: легко отлаживать (curl, браузер).
GraphQL: дебаг через GraphiQL/Apollo Studio; трассировка полей сложнее (нужны field-level metrics).
gRPC: бинарные пакеты труднее смотреть вручную; нужно подходящие инструменты (grpcurl, tshark + protobuf descriptors).
Безопасность и авторизация
REST: стандартные механизмы (OAuth, JWT, TLS).
GraphQL: нужно управлять авторизацией на уровне полей (field-level), чтобы не раскрывать данные; также важны depth-limiting, query complexity limiting, persisted queries.
gRPC: поддерживает mTLS, аутентификацию/авторизацию через metadata; access control реализуется в сервисах.
Количество сетевых вызовов / latency
GraphQL часто уменьшает RTT за счёт агрегации (один запрос вместо множества).
gRPC уменьшает сетевые накладные расходы: меньше байт, лучше TCP connection reuse, HTTP/2 мультиплексирование.
#Java #middle #GraphQL
публичный HTTP API для сторонних клиентов (публичная документация)
Выбор: REST или GraphQL
Почему: совместимость, простота, отсутствие необходимости требованиям к бинарному протоколу.
REST, если API простое, CRUD-ориентированное, нужно кэширование по URL и широчайшая совместимость.
GraphQL, если клиенты (много разных) требуют разные наборы данных и важно уменьшить число запросов.
фронтенд (SPA, мобильные клиенты) с разнообразными представлениями
Выбор: GraphQL
Почему: клиент сам формирует shape ответов; экономия round-trips; отличная интеграция с Apollo/Relay; кодогенерация типов для TS/Swift/Kotlin.
внутренняя связь между микросервисами с высокой нагрузкой
Выбор: gRPC
Почему: низкая латентность, компактность, стриминг, строгие контракты, удобная кодогенерация для множества языков.
real-time (чат, телеметрия, видео/аудио)
Выбор: gRPC (bidirectional) или GraphQL Subscriptions (WebSocket)
Почему: gRPC даёт нативный поток; GraphQL Subscriptions удобны для фронтенда, но требуют инфраструктуры и могут быть сложнее в масштабировании.
интеграция с legacy REST-сервисами
Выбор: GraphQL в качестве BFF (Backend-for-Frontend) или REST-шлюз
Почему: GraphQL может агрегировать несколько REST-вызовов и отдать клиенту нужную структуру.
Почему часто комбинируют: GraphQL для клиентов, gRPC для микросервисов
Это распространённый и рациональный паттерн:
Внутренние сервисы общаются по gRPC (эффективно, типобезопасно, стриминг).
BFF / API Gateway (или отдельный GraphQL-сервер) агрегирует данные из gRPC/REST/БД и предоставляет фронту единый, гибкий интерфейс.
Фронтенд работает с GraphQL (или REST), не заботясь о том, как именно данные доставлены внутри инфраструктуры.
Преимущества паттерна:
Отделение оптимизации внутренней сетевой коммуникации (gRPC) от удобства клиентских API (GraphQL).
Централизация логики агрегации и адаптации под клиентов.
Возможность менять внутреннюю реализацию без ломки фронта.
Пример (псевдокод Java resolver, вызывающий gRPC-stub):
// GraphQL resolver
public class UserResolver {
private final UserGrpc.UserBlockingStub userStub;
public UserResolver(UserGrpc.UserBlockingStub userStub) {
this.userStub = userStub;
}
public User getUser(String id) {
UserRequest req = UserRequest.newBuilder().setId(id).build();
UserResponse resp = userStub.getUser(req); // gRPC call to internal service
return mapToGraphQLUser(resp);
}
}
Детальный разбор преимуществ и ограничений
Удобство разработки
REST: быстро стартовать, понятная модель. Но при сложных клиентских потребностях растёт число эндпоинтов.
GraphQL: позволяет фронтенду быстро изменять данные без координации с бэком, но требует работы со схемой и авторизацией на уровне полей.
gRPC: требует .proto и генерации стабов, но даёт сильную типизацию и меньше рутинного кода при изменениях.
Кеширование
REST: простое кеширование по URL (HTTP caches, CDNs).
GraphQL: кеширование сложнее — операция может возвращать разные поля; решения: persisted queries, apollo cache, CDN на уровне persisted queries/operation id.
gRPC: кеширование на транспортном уровне сложнее; обычно кешируют ответы в сервисах.
Отладка и наблюдаемость
REST: легко отлаживать (curl, браузер).
GraphQL: дебаг через GraphiQL/Apollo Studio; трассировка полей сложнее (нужны field-level metrics).
gRPC: бинарные пакеты труднее смотреть вручную; нужно подходящие инструменты (grpcurl, tshark + protobuf descriptors).
Безопасность и авторизация
REST: стандартные механизмы (OAuth, JWT, TLS).
GraphQL: нужно управлять авторизацией на уровне полей (field-level), чтобы не раскрывать данные; также важны depth-limiting, query complexity limiting, persisted queries.
gRPC: поддерживает mTLS, аутентификацию/авторизацию через metadata; access control реализуется в сервисах.
Количество сетевых вызовов / latency
GraphQL часто уменьшает RTT за счёт агрегации (один запрос вместо множества).
gRPC уменьшает сетевые накладные расходы: меньше байт, лучше TCP connection reuse, HTTP/2 мультиплексирование.
#Java #middle #GraphQL
👍1
Практические шаблоны интеграции (patterns)
1) BFF (Backend-for-Frontend) — GraphQL на фронте + gRPC внутри
GraphQL агрегатор (BFF) вызывает gRPC сервисы, комбинирует ответы и отдаёт клиенту.
Позволяет хранить оптимизированные внутр. контракты и независимую клиентскую схему.
2) API Gateway с трансляцией
gRPC Gateway (прокси) экспонирует REST/JSON поверх gRPC-сервисов или наоборот.
Полезно для совместимости с внешними клиентами.
3) Dual API
Предоставлять одновременно REST (для публичного потребления) и GraphQL (для интерактивного фронта).
Поддерживать один источник данных и разные фасады.
4) Persisted Queries + CDN
Для GraphQL: генерировать хэш-запросов (operationId) и кэшировать на CDN; уменьшает payload и риск DoS.
Частые ошибки
Выбор gRPC для публичного браузерного API без gRPC-Web — приведёт к дополнительной сложности (нужен прокси).
GraphQL без контроля сложности — клиенты могут генерировать тяжёлые запросы (глубокая вложенность). Нужно ставить лимиты.
REST для сложной фронт-логики — приведёт к множеству эндпоинтов и оверхеду в клиенте.
Игнорирование кэширования в GraphQL — потеря преимуществ CDN/edge caching; нужен persisted queries или отдельные REST-эндпоинты для тяжелых ресурсов.
Чек-лист для принятия решения (практический)
Клиенты — браузеры? мобильные? сторонние интеграторы?
браузер/мобильный фронт → GraphQL выгоден;
сторонние сторонние потребители → REST предпочтителен (совместимость).
Нужен ли стриминг / двунаправленная связь?
да → gRPC;
нет → GraphQL/REST.
Высокая нагрузка внутри сети (RTT, пропускная способность)?
да → gRPC;
Требуется гибкость выбора полей клиентом и уменьшение запросов?
да → GraphQL;
Требуется простое кеширование через CDN/HTTP?
да → REST (или реализовать persisted queries для GraphQL).
Нужно строгая схема и codegen для многих языков?
gRPC или GraphQL (оба дают schema/codegen).
Рекомендованные архитектурные сочетания (рецепты)
Внутренние микросервисы (gRPC) + GraphQL BFF + браузерный фронт — оптимальный вариант для больших команд: скорость внутри, гибкость для фронтенда.
REST public API + GraphQL internal BFF for web clients — если нужно максимально простое публичное API, но гибкость для своих фронтенд-команд.
gRPC end-to-end — когда все клиенты контролируются и могут использовать gRPC (например, мобильный клиент с gRPC-Web или нативный клиент).
Пример архитектуры
Сценарий: крупное приложение с веб-клиентом и мобильными приложениями + множество микросервисов.
Внутренние микросервисы: общаются по gRPC (protobuf).
Aggregation Layer: GraphQL BFF. Он:
вызывает gRPC сервисы (stub-ы),
использует DataLoader / batching для борьбы с N+1,
кеширует часто запрашиваемые фрагменты,
реализует field-level авторизацию.
Фронтенд: запрашивает GraphQL; для критичных статических ресурсов (изображения) используется CDN.
Преимущество: фронтенд получает гибкий API, внутренние сервисы остаются быстрыми и типобезопасными.
#Java #middle #GraphQL
1) BFF (Backend-for-Frontend) — GraphQL на фронте + gRPC внутри
GraphQL агрегатор (BFF) вызывает gRPC сервисы, комбинирует ответы и отдаёт клиенту.
Позволяет хранить оптимизированные внутр. контракты и независимую клиентскую схему.
2) API Gateway с трансляцией
gRPC Gateway (прокси) экспонирует REST/JSON поверх gRPC-сервисов или наоборот.
Полезно для совместимости с внешними клиентами.
3) Dual API
Предоставлять одновременно REST (для публичного потребления) и GraphQL (для интерактивного фронта).
Поддерживать один источник данных и разные фасады.
4) Persisted Queries + CDN
Для GraphQL: генерировать хэш-запросов (operationId) и кэшировать на CDN; уменьшает payload и риск DoS.
Частые ошибки
Выбор gRPC для публичного браузерного API без gRPC-Web — приведёт к дополнительной сложности (нужен прокси).
GraphQL без контроля сложности — клиенты могут генерировать тяжёлые запросы (глубокая вложенность). Нужно ставить лимиты.
REST для сложной фронт-логики — приведёт к множеству эндпоинтов и оверхеду в клиенте.
Игнорирование кэширования в GraphQL — потеря преимуществ CDN/edge caching; нужен persisted queries или отдельные REST-эндпоинты для тяжелых ресурсов.
Чек-лист для принятия решения (практический)
Клиенты — браузеры? мобильные? сторонние интеграторы?
браузер/мобильный фронт → GraphQL выгоден;
сторонние сторонние потребители → REST предпочтителен (совместимость).
Нужен ли стриминг / двунаправленная связь?
да → gRPC;
нет → GraphQL/REST.
Высокая нагрузка внутри сети (RTT, пропускная способность)?
да → gRPC;
Требуется гибкость выбора полей клиентом и уменьшение запросов?
да → GraphQL;
Требуется простое кеширование через CDN/HTTP?
да → REST (или реализовать persisted queries для GraphQL).
Нужно строгая схема и codegen для многих языков?
gRPC или GraphQL (оба дают schema/codegen).
Рекомендованные архитектурные сочетания (рецепты)
Внутренние микросервисы (gRPC) + GraphQL BFF + браузерный фронт — оптимальный вариант для больших команд: скорость внутри, гибкость для фронтенда.
REST public API + GraphQL internal BFF for web clients — если нужно максимально простое публичное API, но гибкость для своих фронтенд-команд.
gRPC end-to-end — когда все клиенты контролируются и могут использовать gRPC (например, мобильный клиент с gRPC-Web или нативный клиент).
Пример архитектуры
Сценарий: крупное приложение с веб-клиентом и мобильными приложениями + множество микросервисов.
Внутренние микросервисы: общаются по gRPC (protobuf).
Aggregation Layer: GraphQL BFF. Он:
вызывает gRPC сервисы (stub-ы),
использует DataLoader / batching для борьбы с N+1,
кеширует часто запрашиваемые фрагменты,
реализует field-level авторизацию.
Фронтенд: запрашивает GraphQL; для критичных статических ресурсов (изображения) используется CDN.
Преимущество: фронтенд получает гибкий API, внутренние сервисы остаются быстрыми и типобезопасными.
#Java #middle #GraphQL
👍1