Ключевые идеи:
Publisher-based API: Все операции возвращают Publisher (Mono/Flux из Reactive Streams): Connection как Mono<Connection>, Statement.execute() как Flux<Row>.
Non-blocking от начала до конца: Использует асинхронные драйверы (для PostgreSQL, MySQL и т.д.), где соединения мультиплексируются — одно для многих запросов.
Backpressure встроено: Результаты (Flux<Row>) уважают request(n): если подписчик не готов, БД не шлёт данные, избегая перегрузки.
Транзакции реактивные: Поддержка @Transactional с Mono/Flux.
Интеграция с экосистемой: Spring Data R2DBC — аналог Spring Data JPA, с репозиториями, @Query и CRUD.
Драйверы: r2dbc-postgresql, r2dbc-mysql и т.д. — реализуют спецификацию, используя неблокирующие сокеты (Netty или аналог).
Пример базового R2DBC-кода (без Spring):
Здесь usingWhen — реактивный try-with-resources: создаёт соединение асинхронно, выполняет запрос как Flux<Result>, map извлекает данные. Нет блокировок: если БД медленная, поток свободен.
Spring Data R2DBC: упрощение с репозиториями и аннотациями
Spring Data R2DBC — модуль, который абстрагирует R2DBC, как Spring Data JPA для JDBC.
Добавьте зависимость:
Настройте в application.properties:
Репозитории:
Сущность:
В сервисе/контроллере:
В контроллере:
Это декларативно: repo.findAll() — Flux, который "течёт" из БД без блокировок. Транзакции: @Transactional на методе — reactive, rollback асинхронно.
Расширенный пример: пагинация с ReactiveSortingRepository и Pageable.
Практические советы и подводные камни
Выбор БД: PostgreSQL — лучший для R2DBC (полная поддержка async).
Тестирование: Embedded H2 с r2dbc-h2, ReactiveTest для StepVerifier.
Камень: Нет full ORM (как JPA entities с relations) — используйте ручные joins или Spring Data Projections.
Камень: Транзакции не поддерживают propagation в nested методах fully — будьте осторожны.
Совет: Для hybrid (JDBC + R2DBC) — используйте разные DataSource, но избегайте в одном приложении.
Совет: Мониторьте с Micrometer: метрики на запросы, соединения.
#Java #middle #Reactor #WebFlux #Mono #Flux #R2DBC
Publisher-based API: Все операции возвращают Publisher (Mono/Flux из Reactive Streams): Connection как Mono<Connection>, Statement.execute() как Flux<Row>.
Non-blocking от начала до конца: Использует асинхронные драйверы (для PostgreSQL, MySQL и т.д.), где соединения мультиплексируются — одно для многих запросов.
Backpressure встроено: Результаты (Flux<Row>) уважают request(n): если подписчик не готов, БД не шлёт данные, избегая перегрузки.
Транзакции реактивные: Поддержка @Transactional с Mono/Flux.
Интеграция с экосистемой: Spring Data R2DBC — аналог Spring Data JPA, с репозиториями, @Query и CRUD.
Драйверы: r2dbc-postgresql, r2dbc-mysql и т.д. — реализуют спецификацию, используя неблокирующие сокеты (Netty или аналог).
Пример базового R2DBC-кода (без Spring):
import io.r2dbc.spi.ConnectionFactories;
import io.r2dbc.spi.ConnectionFactory;
import reactor.core.publisher.Flux;
public void createConnectionFactory () {
ConnectionFactory factory = ConnectionFactories.get("r2dbc:postgresql://localhost:5432/db?username=user&password=pass");
Flux<String> namesFlux = Flux.usingWhen(
factory.create(), // Асинхронно создать соединение
conn -> conn.createStatement("SELECT name FROM users").execute().flatMap(result -> result.map((row, metadata) -> row.get("name", String.class))),
conn -> conn.close() // Асинхронно закрыть
);
namesFlux.subscribe(System.out::println); // Строки приходят асинхронно
}
Здесь usingWhen — реактивный try-with-resources: создаёт соединение асинхронно, выполняет запрос как Flux<Result>, map извлекает данные. Нет блокировок: если БД медленная, поток свободен.
Spring Data R2DBC: упрощение с репозиториями и аннотациями
Spring Data R2DBC — модуль, который абстрагирует R2DBC, как Spring Data JPA для JDBC.
Добавьте зависимость:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-r2dbc</artifactId>
</dependency>
<dependency>
<groupId>io.r2dbc</groupId>
<artifactId>r2dbc-postgresql</artifactId> <!-- Для PostgreSQL -->
</dependency>
Настройте в application.properties:
spring.r2dbc.url=r2dbc:postgresql://localhost:5432/db
spring.r2dbc.username=user
spring.r2dbc.password=pass
Репозитории:
ReactiveRepository extends ReactiveCrudRepository<Entity, ID>.
Сущность:
@Entity
public class User {
@Id
private Long id;
private String name;
// Getters/setters
}
public interface UserRepository extends ReactiveCrudRepository<User, Long> {
@Query("SELECT * FROM users WHERE name LIKE :name")
Flux<User> findByNameLike(String name);
}
В сервисе/контроллере:
@Service
public class UserService {
private final UserRepository repo;
public UserService(UserRepository repo) {
this.repo = repo;
}
public Flux<User> findAll() {
return repo.findAll(); // Flux асинхронно
}
public Mono<User> save(User user) {
return repo.save(user);
}
}
В контроллере:
@GetMapping("/users")
public Flux<User> getAllUsers() {
return userService.findAll();
}Это декларативно: repo.findAll() — Flux, который "течёт" из БД без блокировок. Транзакции: @Transactional на методе — reactive, rollback асинхронно.
Расширенный пример: пагинация с ReactiveSortingRepository и Pageable.
public interface UserRepository extends ReactiveSortingRepository<User, Long> {}
Flux<User> paged = repo.findAll(Sort.by("name").ascending()).skip(10).take(20); // Простая пагинация
Для complex: используйте @Query с параметрами, или Criteria API.Практические советы и подводные камни
Выбор БД: PostgreSQL — лучший для R2DBC (полная поддержка async).
Тестирование: Embedded H2 с r2dbc-h2, ReactiveTest для StepVerifier.
Камень: Нет full ORM (как JPA entities с relations) — используйте ручные joins или Spring Data Projections.
Камень: Транзакции не поддерживают propagation в nested методах fully — будьте осторожны.
Совет: Для hybrid (JDBC + R2DBC) — используйте разные DataSource, но избегайте в одном приложении.
Совет: Мониторьте с Micrometer: метрики на запросы, соединения.
#Java #middle #Reactor #WebFlux #Mono #Flux #R2DBC
👍2
Реактивное программирование
Горячие и холодные Publisher’ы в реактивном программировании
Publisher — это источник данных в Reactive Streams, который "толкает" элементы подписчикам (Subscriber). Но не все Publisher’ы одинаковы по поведению при множественных подписках. Это зависит от того, генерирует ли он данные независимо от подписчиков (горячий) или заново для каждого (холодный).
Холодный Publisher (Cold Publisher): Данные генерируются лениво — только при подписке, и для каждого подписчика отдельно. Это как видео по запросу: каждый зритель получает свою копию потока. Плюс: свежие данные каждый раз. Минус: если источник дорогой (запрос в БД, вычисления), повторяется зря.
Горячий Publisher (Hot Publisher): Данные генерируются независимо от подписчиков — поток "вещает" непрерывно. Подписчики "подключаются" к существующему потоку и получают данные с момента подписки. Это как живой эфир: все слушают одно и то же, но опоздавшие пропускают начало. Плюс: экономия ресурсов (один источник). Минус: данные могут быть "старыми" или пропущенными.
В Project Reactor большинство конструкторов — холодные (just, fromIterable, range), но есть горячие (interval, push). Поведение можно менять операторами (share, cache).
Примеры холодных Publisher’ов: ленивость и независимость
Холодные — default в Reactor: подписка запускает генерацию заново.
Пример с Mono (одиночный элемент, но принцип тот же):
С Flux:
Примеры горячих Publisher’ов: общий поток и вещание
Горячие — генерируют данные один раз, подписчики "присоединяются".
Пример с Flux.push (горячий по дизайну):
Другой горячий:
#Java #middle #Reactor #WebFlux #Mono #Flux
Горячие и холодные Publisher’ы в реактивном программировании
Publisher — это источник данных в Reactive Streams, который "толкает" элементы подписчикам (Subscriber). Но не все Publisher’ы одинаковы по поведению при множественных подписках. Это зависит от того, генерирует ли он данные независимо от подписчиков (горячий) или заново для каждого (холодный).
Холодный Publisher (Cold Publisher): Данные генерируются лениво — только при подписке, и для каждого подписчика отдельно. Это как видео по запросу: каждый зритель получает свою копию потока. Плюс: свежие данные каждый раз. Минус: если источник дорогой (запрос в БД, вычисления), повторяется зря.
Горячий Publisher (Hot Publisher): Данные генерируются независимо от подписчиков — поток "вещает" непрерывно. Подписчики "подключаются" к существующему потоку и получают данные с момента подписки. Это как живой эфир: все слушают одно и то же, но опоздавшие пропускают начало. Плюс: экономия ресурсов (один источник). Минус: данные могут быть "старыми" или пропущенными.
В Project Reactor большинство конструкторов — холодные (just, fromIterable, range), но есть горячие (interval, push). Поведение можно менять операторами (share, cache).
Примеры холодных Publisher’ов: ленивость и независимость
Холодные — default в Reactor: подписка запускает генерацию заново.
Пример с Mono (одиночный элемент, но принцип тот же):
Mono<String> coldMono = Mono.fromCallable(() -> {
System.out.println("Генерация данных...");
return "Данные";
});
coldMono.subscribe(System.out::println); // Вывод: "Генерация данных..." и "Данные"
coldMono.subscribe(System.out::println); // Снова: "Генерация данных..." и "Данные"
Каждый subscribe() вызывает fromCallable заново — данные свежие, но если это запрос в API, будет два вызова.С Flux:
Flux<Integer> coldFlux = Flux.range(1, 3).doOnSubscribe(sub -> System.out.println("Новая подписка!"));
coldFlux.subscribe(val -> System.out.println("Подписчик 1: " + val));
coldFlux.subscribe(val -> System.out.println("Подписчик 2: " + val));
// Вывод: "Новая подписка!" + 1,2,3 для первого; "Новая подписка!" + 1,2,3 для второго
Каждый подписчик получает полный поток независимо. Полезно для idempotent операций (без side-effects), как чтение статичных данных.
Асинхронный пример: coldFlux = Flux.interval(Duration.ofSeconds(1)).take(3); // Каждый subscribe() запускает свой таймер.Примеры горячих Publisher’ов: общий поток и вещание
Горячие — генерируют данные один раз, подписчики "присоединяются".
Пример с Flux.push (горячий по дизайну):
ConnectableFlux<Integer> hotFlux = Flux.push(sink -> {
// Симулируем внешний источник
new Thread(() -> {
for (int i = 1; i <= 3; i++) {
try { Thread.sleep(1000); } catch (InterruptedException e) {}
sink.next(i);
}
sink.complete();
}).start();
});
hotFlux.subscribe(val -> System.out.println("Подписчик 1: " + val));
Thread.sleep(1500); // Ждём, чтобы пропустить начало
hotFlux.subscribe(val -> System.out.println("Подписчик 2: " + val));
hotFlux.connect(); // Запуск горячего
// Вывод примерно: Подписчик 1: 1 (1с), 2 (2с), 3 (3с); Подписчик 2: 2 (присоединился после 1), 3
Второй пропустил 1 — поток общий. Connect() — триггер для ConnectableFlux (обёртка для горячих).Другой горячий:
Flux.interval(Duration.ofSeconds(1)) — бесконечный таймер, вещает независимо.
Оператор share(): Делает холодный горячим.
Flux<Integer> shared = coldFlux.share();
shared.subscribe(...); // Запускает
shared.subscribe(...); // Присоединяется к существующему
#Java #middle #Reactor #WebFlux #Mono #Flux
👍2
Переключение типов: операторы для контроля
Из холодного в горячий: share() (для Flux), cache() (кэширует элементы для повторов), publish() (ConnectableFlux с backpressure).
Пример cache:
coldMono.cache() — первый subscribe генерирует, последующие — из кэша.
Из горячего в холодный: Редко нужно, но replay() на ConnectableFlux кэширует историю для новых подписчиков.
Сценарии:
Холодный: Запросы к БД (каждый клиент — свежие данные).
Горячий: Мониторинг (один сенсор — всем подписчикам), стриминг событий (Kafka topic).
Практические советы и подводные камни
Диагностика: doOnSubscribe(() -> log("Subscribe")) — увидите, сколько раз запускается.
Камень: Холодный с side-effects (мутации) — непредсказуемо при множественных подписках; используйте defer() для ленивости.
Камень: Горячий бесконечный без take() — утечки; добавьте refCount() на publish() для авто-отписки при 0 подписчиках.
Совет: В WebFlux — Flux из БД (R2DBC, пост 17) холодный по умолчанию; share() для кэширования результатов.
Тестирование: StepVerifier с .publish() для симуляции горячих.
#Java #middle #Reactor #WebFlux #Mono #Flux
Из холодного в горячий: share() (для Flux), cache() (кэширует элементы для повторов), publish() (ConnectableFlux с backpressure).
Пример cache:
coldMono.cache() — первый subscribe генерирует, последующие — из кэша.
Из горячего в холодный: Редко нужно, но replay() на ConnectableFlux кэширует историю для новых подписчиков.
Сценарии:
Холодный: Запросы к БД (каждый клиент — свежие данные).
Горячий: Мониторинг (один сенсор — всем подписчикам), стриминг событий (Kafka topic).
Практические советы и подводные камни
Диагностика: doOnSubscribe(() -> log("Subscribe")) — увидите, сколько раз запускается.
Камень: Холодный с side-effects (мутации) — непредсказуемо при множественных подписках; используйте defer() для ленивости.
Камень: Горячий бесконечный без take() — утечки; добавьте refCount() на publish() для авто-отписки при 0 подписчиках.
Совет: В WebFlux — Flux из БД (R2DBC, пост 17) холодный по умолчанию; share() для кэширования результатов.
Тестирование: StepVerifier с .publish() для симуляции горячих.
#Java #middle #Reactor #WebFlux #Mono #Flux
👍3
Что такое gRPC и зачем он нужен
Представьте, что ваши программы — это люди в огромном городе. Им нужно обмениваться информацией: один спрашивает адрес, другой — погоду, третий — заказывает еду. Если они общаются письмами (медленно и объемно), то город встанет в пробке. А если по телефону — быстро, четко и без лишних слов?
Вот gRPC (высокопроизводительный фреймворк для удаленного вызова процедур) — это как суперсовременная телефонная сеть для программ. Он позволяет одной программе вызывать функции в другой, как будто они работают на одном компьютере, но через интернет или сеть.
Зачем изучать gRPC в 2025 году? Потому что мир софта ушел от простых сайтов к сложным системам: миллиарды устройств в интернете вещей, тысячи микросервисов в компаниях вроде Netflix или Uber. Обычные веб-API (как REST) здесь тормозят — gRPC ускоряет всё в 7–10 раз, экономит трафик и упрощает разработку.
Что такое RPC: Простое объяснение концепции удаленного вызова процедур
Удаленный вызов процедур (RPC — Remote Procedure Call) — это идея, где программа А "звонит" программе Б и говорит: "Выполни эту функцию и верни результат". Всё выглядит как обычный вызов локальной функции: передаешь данные, ждешь ответ — и готово. Никаких сложностей с сетью на уровне кода.
Пример из жизни: Вы в приложении нажимаете "Получить погоду" — ваше мобильное app вызывает функцию на сервере метеослужбы. Сервер считает, возвращает данные. В gRPC это пишется так же просто:
Без RPC пришлось бы вручную формировать запросы, парсить ответы — утомительно. gRPC автоматизирует всё: генерирует готовый код, управляет соединением и ошибками. В итоге — код чище, быстрее и надежнее.
Разница gRPC с REST: Почему RPC побеждает в скорости и гибкости
REST (Representational State Transfer — архитектурный стиль для веб-API) — популярный подход, где API строится вокруг эндпоинтов для получения данных. Использует HTTP-методы (GET, POST), текст в формате JSON. Просто читать человеку, но медленно для машин.
Вот ключевые различия:
Формат данных: REST — текст (JSON, большой и медленный), gRPC — бинарный (компактный, в 3–10 раз меньше). JSON "Привет, мир!" — 15 байт, в gRPC — 5 байт.
Скорость: gRPC на HTTP/2 (мультиплексирование — много запросов по одному каналу) в 7 раз быстрее при приеме данных, в 10 раз — при отправке. Идеально для мобильного интернета.
Гибкость общения: REST — только "запрос-ответ". gRPC поддерживает стриминг (поток сообщений): сервер шлет обновления в реальном времени (как чат), клиент загружает файлы порциями, или оба общаются одновременно.
Языки и платформы: REST — универсален, но код пишется вручную. gRPC генерирует код для 10+ языков (Python, Go, Java) из одного описания — никаких несоответствий.
Отладка: REST читаем в браузере, gRPC — бинарный, но есть инструменты вроде gRPCurl (аналог curl).
REST хорош для публичных API (сайты, простые apps). gRPC — для внутренних систем, где важна производительность. В 2025 году компании комбинируют: REST снаружи, gRPC внутри.
#Java #middle #gRPC
Представьте, что ваши программы — это люди в огромном городе. Им нужно обмениваться информацией: один спрашивает адрес, другой — погоду, третий — заказывает еду. Если они общаются письмами (медленно и объемно), то город встанет в пробке. А если по телефону — быстро, четко и без лишних слов?
Вот gRPC (высокопроизводительный фреймворк для удаленного вызова процедур) — это как суперсовременная телефонная сеть для программ. Он позволяет одной программе вызывать функции в другой, как будто они работают на одном компьютере, но через интернет или сеть.
Зачем изучать gRPC в 2025 году? Потому что мир софта ушел от простых сайтов к сложным системам: миллиарды устройств в интернете вещей, тысячи микросервисов в компаниях вроде Netflix или Uber. Обычные веб-API (как REST) здесь тормозят — gRPC ускоряет всё в 7–10 раз, экономит трафик и упрощает разработку.
Что такое RPC: Простое объяснение концепции удаленного вызова процедур
Удаленный вызов процедур (RPC — Remote Procedure Call) — это идея, где программа А "звонит" программе Б и говорит: "Выполни эту функцию и верни результат". Всё выглядит как обычный вызов локальной функции: передаешь данные, ждешь ответ — и готово. Никаких сложностей с сетью на уровне кода.
Пример из жизни: Вы в приложении нажимаете "Получить погоду" — ваше мобильное app вызывает функцию на сервере метеослужбы. Сервер считает, возвращает данные. В gRPC это пишется так же просто:
Клиент (ваше app): ответ = сервер.ПолучитьПогоду(город="Москва")
Сервер: выполняет расчет и отдает результат.
Без RPC пришлось бы вручную формировать запросы, парсить ответы — утомительно. gRPC автоматизирует всё: генерирует готовый код, управляет соединением и ошибками. В итоге — код чище, быстрее и надежнее.
Разница gRPC с REST: Почему RPC побеждает в скорости и гибкости
REST (Representational State Transfer — архитектурный стиль для веб-API) — популярный подход, где API строится вокруг эндпоинтов для получения данных. Использует HTTP-методы (GET, POST), текст в формате JSON. Просто читать человеку, но медленно для машин.
Вот ключевые различия:
Формат данных: REST — текст (JSON, большой и медленный), gRPC — бинарный (компактный, в 3–10 раз меньше). JSON "Привет, мир!" — 15 байт, в gRPC — 5 байт.
Скорость: gRPC на HTTP/2 (мультиплексирование — много запросов по одному каналу) в 7 раз быстрее при приеме данных, в 10 раз — при отправке. Идеально для мобильного интернета.
Гибкость общения: REST — только "запрос-ответ". gRPC поддерживает стриминг (поток сообщений): сервер шлет обновления в реальном времени (как чат), клиент загружает файлы порциями, или оба общаются одновременно.
Языки и платформы: REST — универсален, но код пишется вручную. gRPC генерирует код для 10+ языков (Python, Go, Java) из одного описания — никаких несоответствий.
Отладка: REST читаем в браузере, gRPC — бинарный, но есть инструменты вроде gRPCurl (аналог curl).
REST хорош для публичных API (сайты, простые apps). gRPC — для внутренних систем, где важна производительность. В 2025 году компании комбинируют: REST снаружи, gRPC внутри.
#Java #middle #gRPC
👍2👎1
Почему Google создал gRPC: От внутренних нужд к мировому стандарту
Google — гигант с миллионами микросервисов (маленькие программы, работающие вместе). С 2001 года они использовали внутренний фреймворк Stubby для их связи. Но Stubby был закрытым, и партнерам (Android, YouTube API) приходилось писать свои библиотеки.
В 2015 году Google открыл gRPC: эволюцию Stubby на HTTP/2 и Protocol Buffers (protobuf — бинарный формат для данных).
Цели:
Объединить сервисы в дата-центрах и на устройствах.
Поддержка стриминга для реал-тайма.
Автоматическая генерация кода — один .proto-файл для всех языков.
К 2025 году gRPC — проект CNCF (Cloud Native Computing Foundation), используется в Google Cloud, Netflix (стриминг видео), Uber (поездки в реальном времени), Cisco. За 10 лет обработал триллионы вызовов — доказанная надежность.
Где применяется gRPC: От микросервисов до умных устройств
gRPC — король сценариев с высокой нагрузкой:
Микросервисы: Тысячи маленьких сервисов в Kubernetes (оркестратор контейнеров). Netflix использует для рекомендаций фильмов — миллиарды запросов в секунду без задержек. Внутренняя связь: сервис оплаты "звонит" сервису доставки.
Интернет вещей (IoT): Миллиарды устройств (умные лампочки, датчики). gRPC соединяет их с облаком: низкий трафик, стриминг данных (температура в реальном времени). Пример: умный дом от Google Nest.
Внутренние API: В компаниях — связь backend'ов. Uber: расчет маршрутов между сервисами. Банки: обработка транзакций. Не для клиентов (там REST), а внутри — для скорости.
В 2025: gRPC в AI (TensorFlow), играх (реал-тайм мультиплеер), авто (Tesla — связь машин с облаком).
#Java #middle #gRPC
Google — гигант с миллионами микросервисов (маленькие программы, работающие вместе). С 2001 года они использовали внутренний фреймворк Stubby для их связи. Но Stubby был закрытым, и партнерам (Android, YouTube API) приходилось писать свои библиотеки.
В 2015 году Google открыл gRPC: эволюцию Stubby на HTTP/2 и Protocol Buffers (protobuf — бинарный формат для данных).
Цели:
Объединить сервисы в дата-центрах и на устройствах.
Поддержка стриминга для реал-тайма.
Автоматическая генерация кода — один .proto-файл для всех языков.
К 2025 году gRPC — проект CNCF (Cloud Native Computing Foundation), используется в Google Cloud, Netflix (стриминг видео), Uber (поездки в реальном времени), Cisco. За 10 лет обработал триллионы вызовов — доказанная надежность.
Где применяется gRPC: От микросервисов до умных устройств
gRPC — король сценариев с высокой нагрузкой:
Микросервисы: Тысячи маленьких сервисов в Kubernetes (оркестратор контейнеров). Netflix использует для рекомендаций фильмов — миллиарды запросов в секунду без задержек. Внутренняя связь: сервис оплаты "звонит" сервису доставки.
Интернет вещей (IoT): Миллиарды устройств (умные лампочки, датчики). gRPC соединяет их с облаком: низкий трафик, стриминг данных (температура в реальном времени). Пример: умный дом от Google Nest.
Внутренние API: В компаниях — связь backend'ов. Uber: расчет маршрутов между сервисами. Банки: обработка транзакций. Не для клиентов (там REST), а внутри — для скорости.
В 2025: gRPC в AI (TensorFlow), играх (реал-тайм мультиплеер), авто (Tesla — связь машин с облаком).
#Java #middle #gRPC
👍3
Архитектура gRPC: как всё работает под капотом
gRPC — это современный фреймворк удалённого вызова процедур (RPC, Remote Procedure Call), разработанный Google. Он позволяет приложениям общаться друг с другом как будто они вызывают локальные функции, хотя на самом деле взаимодействие идёт по сети. Чтобы понять, почему gRPC так эффективен, нужно разобрать его архитектуру и то, что происходит «под капотом».
1. Концепция gRPC: RPC-модель нового поколения
RPC (Remote Procedure Call) — это подход, при котором одна программа может вызвать функцию, которая физически исполняется на другом сервере.
В классической модели RPC разработчик просто вызывает метод, а инфраструктура берёт на себя всё — упаковку данных, передачу по сети и распаковку на другой стороне.
gRPC реализует эту идею, но в современном, высокопроизводительном виде — поверх HTTP/2 и с использованием Protocol Buffers для сериализации.
2. Основные участники архитектуры
Клиент (Client)
Это программа, которая инициирует вызов удалённого метода. Она не знает деталей того, как сервер устроен внутри.
Клиент работает с client stub — это локальный объект, который выглядит как обычный класс с методами, но при вызове каждого метода на самом деле выполняется сетевое обращение к серверу.
Сервер (Server)
Это приложение, которое реализует интерфейс, описанный в .proto файле. Сервер принимает запросы от клиентов, обрабатывает их и отправляет ответы.
Client Stub и Server Stub
Что такое Stub
Stub — это «заглушка», или точнее — сгенерированный код, который связывает ваш код с gRPC-инфраструктурой.
Client Stub (клиентская заглушка) — это класс, который содержит методы, соответствующие сервисам, определённым в .proto.
Когда вы вызываете метод stub.buyCar(request), gRPC автоматически:
Сериализует объект request в бинарный формат.
Отправляет его по сети через HTTP/2.
Получает ответ, десериализует и возвращает его как обычный объект Java.
Server Stub — это абстрактный класс, который вы расширяете, чтобы реализовать свою бизнес-логику. Он автоматически принимает входящие вызовы, десериализует данные и вызывает ваш метод.
Пример:
После генерации protoc создаёт классы:
Реализация сервера:
Клиент:
#Java #middle #gRPC
gRPC — это современный фреймворк удалённого вызова процедур (RPC, Remote Procedure Call), разработанный Google. Он позволяет приложениям общаться друг с другом как будто они вызывают локальные функции, хотя на самом деле взаимодействие идёт по сети. Чтобы понять, почему gRPC так эффективен, нужно разобрать его архитектуру и то, что происходит «под капотом».
1. Концепция gRPC: RPC-модель нового поколения
RPC (Remote Procedure Call) — это подход, при котором одна программа может вызвать функцию, которая физически исполняется на другом сервере.
В классической модели RPC разработчик просто вызывает метод, а инфраструктура берёт на себя всё — упаковку данных, передачу по сети и распаковку на другой стороне.
gRPC реализует эту идею, но в современном, высокопроизводительном виде — поверх HTTP/2 и с использованием Protocol Buffers для сериализации.
2. Основные участники архитектуры
Клиент (Client)
Это программа, которая инициирует вызов удалённого метода. Она не знает деталей того, как сервер устроен внутри.
Клиент работает с client stub — это локальный объект, который выглядит как обычный класс с методами, но при вызове каждого метода на самом деле выполняется сетевое обращение к серверу.
Сервер (Server)
Это приложение, которое реализует интерфейс, описанный в .proto файле. Сервер принимает запросы от клиентов, обрабатывает их и отправляет ответы.
Client Stub и Server Stub
Что такое Stub
Stub — это «заглушка», или точнее — сгенерированный код, который связывает ваш код с gRPC-инфраструктурой.
Client Stub (клиентская заглушка) — это класс, который содержит методы, соответствующие сервисам, определённым в .proto.
Когда вы вызываете метод stub.buyCar(request), gRPC автоматически:
Сериализует объект request в бинарный формат.
Отправляет его по сети через HTTP/2.
Получает ответ, десериализует и возвращает его как обычный объект Java.
Server Stub — это абстрактный класс, который вы расширяете, чтобы реализовать свою бизнес-логику. Он автоматически принимает входящие вызовы, десериализует данные и вызывает ваш метод.
Пример:
// .proto файл
syntax = "proto3";
service CarService {
rpc BuyCar (CarRequest) returns (CarResponse);
}
message CarRequest {
string model = 1;
int32 budget = 2;
}
message CarResponse {
string status = 1;
}
После генерации protoc создаёт классы:
CarServiceGrpc.CarServiceImplBase — Server Stub
CarServiceGrpc.CarServiceBlockingStub и CarServiceGrpc.CarServiceFutureStub — Client Stubs
Реализация сервера:
public class CarServiceImpl extends CarServiceGrpc.CarServiceImplBase {
@Override
public void buyCar(CarRequest request, StreamObserver<CarResponse> responseObserver) {
String result = "You bought: " + request.getModel();
CarResponse response = CarResponse.newBuilder()
.setStatus(result)
.build();
responseObserver.onNext(response);
responseObserver.onCompleted();
}
}Клиент:
ManagedChannel channel = ManagedChannelBuilder.forAddress("localhost", 8080)
.usePlaintext()
.build();
CarServiceGrpc.CarServiceBlockingStub stub = CarServiceGrpc.newBlockingStub(channel);
CarRequest request = CarRequest.newBuilder()
.setModel("Tesla Model 3")
.setBudget(50000)
.build();
CarResponse response = stub.buyCar(request);
System.out.println(response.getStatus());#Java #middle #gRPC
👍2
3. Роль Protocol Buffers (protobuf)
Protocol Buffers — это бинарный формат сериализации данных, разработанный Google. Он выполняет две функции:
Описание структуры данных (через .proto файл).
Это аналог схемы JSON или XML, но строгий и типизированный.
Сериализация и десериализация (преобразование объектов в компактную бинарную форму и обратно).
Пример .proto файла не только описывает сообщения, но и определяет сервис (то есть API интерфейс).
Почему protobuf — ключевой элемент:
Он компактен: бинарный формат в несколько раз меньше JSON.
Он типобезопасен: при компиляции проверяются типы.
Он быстр: сериализация и десериализация работают на уровне байтов, без парсинга текста.
4. Как происходит сериализация и десериализация
Сериализация — это процесс превращения объекта в поток байтов для передачи по сети.
Десериализация — обратный процесс.
В gRPC:
Клиент вызывает метод stub.method(request).
request сериализуется с помощью Protocol Buffers в бинарный поток.
Поток отправляется через HTTP/2.
Сервер принимает поток, десериализует его обратно в объект CarRequest.
После обработки сервер сериализует ответ (CarResponse) и отправляет обратно.
Важно: gRPC сам управляет сериализацией. Вам не нужно ничего кодировать вручную — всё делает сгенерированный stub.
5. Что делает protoc и зачем нужны плагины
protoc — это компилятор Protocol Buffers. Он принимает .proto файл и генерирует исходный код для нужного языка.
Например:
gRPC добавляет ещё один плагин — --grpc-java_out, который генерирует код для stub'ов.
Таким образом, protoc создаёт:
Классы-сообщения (CarRequest, CarResponse)
gRPC классы (CarServiceGrpc, Stub и ImplBase)
Для каждого языка есть свой плагин:
--grpc-java_out для Java
--grpc-python_out для Python
--grpc-go_out для Go
и т. д.
Это и есть причина, почему gRPC мультиплатформенный — интерфейс описывается один раз в .proto, а код для всех языков генерируется автоматически.
6. Почему gRPC быстрее REST
gRPC построен поверх HTTP/2, а REST — чаще всего поверх HTTP/1.1. Разница принципиальна.
Ключевые причины производительности:
HTTP/2 поддерживает мультиплексирование — можно отправлять несколько запросов в одном соединении без блокировки.
Сжатие заголовков (HPACK) уменьшает накладные расходы.
Бинарная сериализация (protobuf) — меньше данных, быстрее парсинг.
Постоянное соединение — нет затрат на открытие/закрытие TCP для каждого запроса.
Streaming — можно передавать поток данных, а не ждать полного ответа (например, поток логов или большого файла).
7. Суммарно: что происходит при вызове метода в gRPC
Пошагово:
Клиент вызывает метод stub.someMethod(request).
Stub сериализует объект через protobuf.
Сериализованные данные упаковываются в HTTP/2 фрейм и отправляются на сервер.
Сервер принимает фрейм, десериализует данные.
Вызвается метод реализации (ImplBase).
Сервер формирует ответ, сериализует через protobuf.
Ответ отправляется обратно по тому же соединению.
Клиент получает и десериализует ответ.
Для разработчика — это выглядит как обычный вызов функции.
Под капотом же происходит оптимизированное сетевое взаимодействие с минимальными потерями.
#Java #middle #gRPC
Protocol Buffers — это бинарный формат сериализации данных, разработанный Google. Он выполняет две функции:
Описание структуры данных (через .proto файл).
Это аналог схемы JSON или XML, но строгий и типизированный.
Сериализация и десериализация (преобразование объектов в компактную бинарную форму и обратно).
Пример .proto файла не только описывает сообщения, но и определяет сервис (то есть API интерфейс).
Почему protobuf — ключевой элемент:
Он компактен: бинарный формат в несколько раз меньше JSON.
Он типобезопасен: при компиляции проверяются типы.
Он быстр: сериализация и десериализация работают на уровне байтов, без парсинга текста.
4. Как происходит сериализация и десериализация
Сериализация — это процесс превращения объекта в поток байтов для передачи по сети.
Десериализация — обратный процесс.
В gRPC:
Клиент вызывает метод stub.method(request).
request сериализуется с помощью Protocol Buffers в бинарный поток.
Поток отправляется через HTTP/2.
Сервер принимает поток, десериализует его обратно в объект CarRequest.
После обработки сервер сериализует ответ (CarResponse) и отправляет обратно.
Важно: gRPC сам управляет сериализацией. Вам не нужно ничего кодировать вручную — всё делает сгенерированный stub.
5. Что делает protoc и зачем нужны плагины
protoc — это компилятор Protocol Buffers. Он принимает .proto файл и генерирует исходный код для нужного языка.
Например:
protoc --java_out=./build/generated proto/car.proto
gRPC добавляет ещё один плагин — --grpc-java_out, который генерирует код для stub'ов.
protoc --plugin=protoc-gen-grpc-java=path/to/protoc-gen-grpc-java \
--grpc-java_out=./build/generated \
--java_out=./build/generated \
proto/car.proto
Таким образом, protoc создаёт:
Классы-сообщения (CarRequest, CarResponse)
gRPC классы (CarServiceGrpc, Stub и ImplBase)
Для каждого языка есть свой плагин:
--grpc-java_out для Java
--grpc-python_out для Python
--grpc-go_out для Go
и т. д.
Это и есть причина, почему gRPC мультиплатформенный — интерфейс описывается один раз в .proto, а код для всех языков генерируется автоматически.
6. Почему gRPC быстрее REST
gRPC построен поверх HTTP/2, а REST — чаще всего поверх HTTP/1.1. Разница принципиальна.
Ключевые причины производительности:
HTTP/2 поддерживает мультиплексирование — можно отправлять несколько запросов в одном соединении без блокировки.
Сжатие заголовков (HPACK) уменьшает накладные расходы.
Бинарная сериализация (protobuf) — меньше данных, быстрее парсинг.
Постоянное соединение — нет затрат на открытие/закрытие TCP для каждого запроса.
Streaming — можно передавать поток данных, а не ждать полного ответа (например, поток логов или большого файла).
7. Суммарно: что происходит при вызове метода в gRPC
Пошагово:
Клиент вызывает метод stub.someMethod(request).
Stub сериализует объект через protobuf.
Сериализованные данные упаковываются в HTTP/2 фрейм и отправляются на сервер.
Сервер принимает фрейм, десериализует данные.
Вызвается метод реализации (ImplBase).
Сервер формирует ответ, сериализует через protobuf.
Ответ отправляется обратно по тому же соединению.
Клиент получает и десериализует ответ.
Для разработчика — это выглядит как обычный вызов функции.
Под капотом же происходит оптимизированное сетевое взаимодействие с минимальными потерями.
#Java #middle #gRPC
👍2
Protocol Buffers: сердце gRPC
Если gRPC — это двигатель взаимодействия сервисов, то Protocol Buffers (protobuf) — это его сердце.
Именно protobuf определяет, как описываются данные, как они сериализуются, и как из одной схемы генерируются типобезопасные классы для разных языков.
Чтобы по-настоящему понимать gRPC, нужно уверенно работать с .proto-файлами.
1. Что такое .proto файл
.proto — это файл описания структуры данных и интерфейсов (API).
Он играет сразу три роли:
Документирует контракт между клиентом и сервером (описывает, какие методы и какие данные доступны).
Генерирует код для разных языков с помощью protoc (компилятора Protocol Buffers).
Определяет схему сериализации — то, как объекты превращаются в байты и обратно.
Фактически .proto — это единый источник правды для вашего API.
2. Базовая структура .proto файла
Пример простого файла:
3. Ключевые элементы .proto
3.1. syntax
Первая строка файла:
Обязательно указывает версию синтаксиса.
На практике используется только proto3, потому что она проще, строже типизирована и лучше поддерживается в gRPC.
3.2. package
Задает логическое пространство имён, чтобы избежать конфликтов:
В Java и других языках это превращается в пакеты/модули.
3.3. option
Позволяет задавать настройки генерации кода, например:
Без этого весь код попадёт в один файл, что неудобно для больших схем.
3.4. message — описание структуры данных
message — это аналог класса в объектно-ориентированных языках.
Каждое поле внутри него — это свойство (переменная), которое сериализуется в бинарный поток.
Пример:
3.5. enum — перечисление значений
enum — это список допустимых констант.
Значение 0 обязательно — это значение по умолчанию.
При сериализации хранится не текстовое имя ("ACTIVE"), а его числовое значение (0), что делает protobuf компактным.
3.6. service — описание API
service определяет набор удалённых методов, которые сервер предоставляет клиенту.
Это аналог интерфейса в Java:
Каждый rpc определяет:
имя метода (BuyCar),
входной тип (CarRequest),
выходной тип (CarResponse).
4. Типы данных в Protocol Buffers
Protobuf поддерживает ограниченный, но универсальный набор типов.
Некоторые часто используемые:
string - Текст
bool - Логическое значение
int32, int64 - Целые числа
float, double - Числа с плавающей точкой
bytes - Массив байтов
repeated - Массив
map<key, value> - Словарь
Пример:
#Java #middle #gRPC #proto
Если gRPC — это двигатель взаимодействия сервисов, то Protocol Buffers (protobuf) — это его сердце.
Именно protobuf определяет, как описываются данные, как они сериализуются, и как из одной схемы генерируются типобезопасные классы для разных языков.
Чтобы по-настоящему понимать gRPC, нужно уверенно работать с .proto-файлами.
1. Что такое .proto файл
.proto — это файл описания структуры данных и интерфейсов (API).
Он играет сразу три роли:
Документирует контракт между клиентом и сервером (описывает, какие методы и какие данные доступны).
Генерирует код для разных языков с помощью protoc (компилятора Protocol Buffers).
Определяет схему сериализации — то, как объекты превращаются в байты и обратно.
Фактически .proto — это единый источник правды для вашего API.
2. Базовая структура .proto файла
Пример простого файла:
syntax = "proto3";
package car;
option java_multiple_files = true;
option java_package = "com.example.car";
option java_outer_classname = "CarProto";
// Определение сообщений
message Car {
string model = 1;
int32 year = 2;
CarStatus status = 3;
}
// Перечисление (enum)
enum CarStatus {
ACTIVE = 0;
INACTIVE = 1;
}
// Определение сервиса
service CarService {
rpc BuyCar (CarRequest) returns (CarResponse);
}
message CarRequest {
string model = 1;
}
message CarResponse {
string confirmation = 1;
}
3. Ключевые элементы .proto
3.1. syntax
Первая строка файла:
syntax = "proto3";
Обязательно указывает версию синтаксиса.
На практике используется только proto3, потому что она проще, строже типизирована и лучше поддерживается в gRPC.
3.2. package
Задает логическое пространство имён, чтобы избежать конфликтов:
package car;
В Java и других языках это превращается в пакеты/модули.
3.3. option
Позволяет задавать настройки генерации кода, например:
option java_package = "com.example.car";
option java_multiple_files = true;
option java_outer_classname = "CarProto";
Без этого весь код попадёт в один файл, что неудобно для больших схем.
3.4. message — описание структуры данных
message — это аналог класса в объектно-ориентированных языках.
Каждое поле внутри него — это свойство (переменная), которое сериализуется в бинарный поток.
Пример:
message User {
string name = 1;
int32 age = 2;
repeated string hobbies = 3;
}
string name = 1; — поле с типом string и номером 1.
int32 age = 2; — целочисленное поле.
repeated string hobbies = 3; — массив строк.
Важно: номер поля (= 1, = 2, = 3) — это не просто индекс. Это ключ в бинарной сериализации, который должен быть уникален и неизменен.3.5. enum — перечисление значений
enum — это список допустимых констант.
enum CarStatus {
ACTIVE = 0;
INACTIVE = 1;
SOLD = 2;
}Значение 0 обязательно — это значение по умолчанию.
При сериализации хранится не текстовое имя ("ACTIVE"), а его числовое значение (0), что делает protobuf компактным.
3.6. service — описание API
service определяет набор удалённых методов, которые сервер предоставляет клиенту.
Это аналог интерфейса в Java:
service CarService {
rpc BuyCar (CarRequest) returns (CarResponse);
rpc ListCars (Empty) returns (CarList);
}Каждый rpc определяет:
имя метода (BuyCar),
входной тип (CarRequest),
выходной тип (CarResponse).
4. Типы данных в Protocol Buffers
Protobuf поддерживает ограниченный, но универсальный набор типов.
Некоторые часто используемые:
string - Текст
bool - Логическое значение
int32, int64 - Целые числа
float, double - Числа с плавающей точкой
bytes - Массив байтов
repeated - Массив
map<key, value> - Словарь
Пример:
message Garage {
map<string, Car> cars = 1;
}#Java #middle #gRPC #proto
👍2
5. Нумерация полей — почему это критично
Каждое поле имеет свой уникальный номер — это его идентификатор в бинарном потоке.
Если поменять номера, клиент и сервер перестанут понимать друг друга.
Например, если у старой версии клиента year = 2, а у новой year = 3, при сериализации они будут читать разные данные.
6. Почему важно резервировать поля
Когда вы удаляете или переименовываете поле, нельзя просто убрать строку — нужно зарезервировать номер и имя.
Пример:
Это предотвращает случайное переиспользование старого номера под другое поле, что может привести к неправильной интерпретации данных.
7. Эволюция и миграция схем (Schema Evolution)
Protobuf специально спроектирован так, чтобы позволять обновлять схемы без поломки совместимости.
Главное — соблюдать несколько правил.
Что можно делать безопасно:
Добавлять новые поля с новыми номерами.
Удалять поля (с их резервированием).
Изменять имя поля (номер должен остаться прежним).
Изменять порядок полей — не влияет на сериализацию.
Что делать нельзя:
Менять тип поля (например, int32 → string).
Менять номер поля.
Удалять поле без reserved.
Пример миграции
Старая версия:
Новая версия:
Старый клиент, который не знает про email, просто проигнорирует это поле.
А новый клиент не столкнётся с конфликтом, потому что старый 2 зарезервирован.
8. Компиляция .proto файла и генерация кода
protoc — компилятор, который читает .proto и создаёт Java-классы.
Пример команды:
Результат:
Для каждого message создаются классы с Builder-паттерном.
Для service создаются классы CarServiceGrpc, CarServiceImplBase, CarServiceStub.
9. Пример полного цикла
Файл car.proto:
Сгенерированный код в Java (упрощённо):
Серверная реализация:
#Java #middle #gRPC #proto
Каждое поле имеет свой уникальный номер — это его идентификатор в бинарном потоке.
message Car {
string model = 1;
int32 year = 2;
}Если поменять номера, клиент и сервер перестанут понимать друг друга.
Например, если у старой версии клиента year = 2, а у новой year = 3, при сериализации они будут читать разные данные.
6. Почему важно резервировать поля
Когда вы удаляете или переименовываете поле, нельзя просто убрать строку — нужно зарезервировать номер и имя.
Пример:
message Car {
string model = 1;
reserved 2; // резервируем номер
reserved "status_old"; // резервируем имя
}Это предотвращает случайное переиспользование старого номера под другое поле, что может привести к неправильной интерпретации данных.
7. Эволюция и миграция схем (Schema Evolution)
Protobuf специально спроектирован так, чтобы позволять обновлять схемы без поломки совместимости.
Главное — соблюдать несколько правил.
Что можно делать безопасно:
Добавлять новые поля с новыми номерами.
Удалять поля (с их резервированием).
Изменять имя поля (номер должен остаться прежним).
Изменять порядок полей — не влияет на сериализацию.
Что делать нельзя:
Менять тип поля (например, int32 → string).
Менять номер поля.
Удалять поле без reserved.
Пример миграции
Старая версия:
message User {
string name = 1;
int32 age = 2;
}Новая версия:
message User {
string name = 1;
reserved 2;
string email = 3;
}Старый клиент, который не знает про email, просто проигнорирует это поле.
А новый клиент не столкнётся с конфликтом, потому что старый 2 зарезервирован.
8. Компиляция .proto файла и генерация кода
protoc — компилятор, который читает .proto и создаёт Java-классы.
Пример команды:
protoc \
--java_out=./build/generated \
--grpc-java_out=./build/generated \
proto/car.proto
Результат:
Для каждого message создаются классы с Builder-паттерном.
Для service создаются классы CarServiceGrpc, CarServiceImplBase, CarServiceStub.
9. Пример полного цикла
Файл car.proto:
syntax = "proto3";
service CarService {
rpc BuyCar (CarRequest) returns (CarResponse);
}
message CarRequest {
string model = 1;
int32 budget = 2;
}
message CarResponse {
string message = 1;
}
Сгенерированный код в Java (упрощённо):
// Отправитель (клиент)
CarRequest request = CarRequest.newBuilder()
.setModel("BMW")
.setBudget(20000)
.build();
CarResponse response = stub.buyCar(request);
System.out.println(response.getMessage());
Серверная реализация:
public class CarServiceImpl extends CarServiceGrpc.CarServiceImplBase {
@Override
public void buyCar(CarRequest request, StreamObserver<CarResponse> responseObserver) {
String msg = "Car purchased: " + request.getModel();
CarResponse response = CarResponse.newBuilder().setMessage(msg).build();
responseObserver.onNext(response);
responseObserver.onCompleted();
}
}#Java #middle #gRPC #proto
👍3
Типы RPC в gRPC
Одно из ключевых преимуществ gRPC — это гибкость модели обмена данными.
REST традиционно работает в стиле “один запрос — один ответ”.
gRPC, в отличие от него, поддерживает четыре типа взаимодействия, и каждый из них решает свою задачу.
1. Unary RPC (один запрос — один ответ)
Это самый простой и самый распространённый тип — аналог классического REST-вызова.
Клиент отправляет один запрос, сервер обрабатывает его и возвращает один ответ.
Клиент → (один запрос) → Сервер
Сервер → (один ответ) → Клиент
Пример .proto
Сервер (Java)
Клиент
Где применяется:
CRUD-операции (создание, получение, обновление, удаление).
Любые точечные вызовы, где не требуется поток данных.
По сути: это "REST, но бинарный, типобезопасный и в 10 раз быстрее".
2. Server Streaming RPC (поток ответов от сервера)
В этом типе клиент делает один запрос, а сервер возвращает несколько ответов последовательно — поток сообщений.
Клиент → (один запрос) → Сервер
Сервер → (много ответов в потоке) → Клиент
Сеанс продолжается, пока сервер не закончит отправку данных.
Пример .proto
Сервер (Java)
Клиент
Где применяется:
Поток обновлений или уведомлений.
Стриминг данных (например, список записей, логи, результаты аналитики).
Долгие вычисления, когда сервер постепенно отдаёт результаты.
Пример из реального мира:
Сервер передаёт клиенту “живой” поток котировок акций или данных из IoT-устройств.
#Java #middle #gRPC #proto
Одно из ключевых преимуществ gRPC — это гибкость модели обмена данными.
REST традиционно работает в стиле “один запрос — один ответ”.
gRPC, в отличие от него, поддерживает четыре типа взаимодействия, и каждый из них решает свою задачу.
1. Unary RPC (один запрос — один ответ)
Это самый простой и самый распространённый тип — аналог классического REST-вызова.
Клиент отправляет один запрос, сервер обрабатывает его и возвращает один ответ.
Клиент → (один запрос) → Сервер
Сервер → (один ответ) → Клиент
Пример .proto
service UserService {
rpc GetUser (UserRequest) returns (UserResponse);
}
message UserRequest {
int32 id = 1;
}
message UserResponse {
string name = 1;
int32 age = 2;
}Сервер (Java)
public class UserServiceImpl extends UserServiceGrpc.UserServiceImplBase {
@Override
public void getUser(UserRequest request, StreamObserver<UserResponse> responseObserver) {
UserResponse response = UserResponse.newBuilder()
.setName("Alice")
.setAge(30)
.build();
responseObserver.onNext(response);
responseObserver.onCompleted();
}
}Клиент
UserResponse response = stub.getUser(
UserRequest.newBuilder().setId(1).build()
);
System.out.println(response.getName());
Где применяется:
CRUD-операции (создание, получение, обновление, удаление).
Любые точечные вызовы, где не требуется поток данных.
По сути: это "REST, но бинарный, типобезопасный и в 10 раз быстрее".
2. Server Streaming RPC (поток ответов от сервера)
В этом типе клиент делает один запрос, а сервер возвращает несколько ответов последовательно — поток сообщений.
Клиент → (один запрос) → Сервер
Сервер → (много ответов в потоке) → Клиент
Сеанс продолжается, пока сервер не закончит отправку данных.
Пример .proto
service OrderService {
rpc ListOrders (OrdersRequest) returns (stream Order);
}
message OrdersRequest {
string user = 1;
}
message Order {
string id = 1;
string product = 2;
}Сервер (Java)
public class OrderServiceImpl extends OrderServiceGrpc.OrderServiceImplBase {
@Override
public void listOrders(OrdersRequest request, StreamObserver<Order> responseObserver) {
for (int i = 1; i <= 3; i++) {
Order order = Order.newBuilder()
.setId("ORD-" + i)
.setProduct("Product " + i)
.build();
responseObserver.onNext(order);
try { Thread.sleep(1000); } catch (InterruptedException ignored) {}
}
responseObserver.onCompleted();
}
}Клиент
stub.listOrders(OrdersRequest.newBuilder().setUser("Bob").build())
.forEachRemaining(order -> System.out.println(order.getProduct()));Где применяется:
Поток обновлений или уведомлений.
Стриминг данных (например, список записей, логи, результаты аналитики).
Долгие вычисления, когда сервер постепенно отдаёт результаты.
Пример из реального мира:
Сервер передаёт клиенту “живой” поток котировок акций или данных из IoT-устройств.
#Java #middle #gRPC #proto
👍2
3. Client Streaming RPC (поток запросов от клиента)
Теперь наоборот — клиент отправляет поток запросов, а сервер отвечает одним итоговым сообщением.
Клиент → (много запросов) → Сервер
Сервер → (один ответ) → Клиент
Это удобно, когда клиенту нужно собрать несколько событий или пакетов данных и отправить их вместе.
Пример .proto
Сервер (Java)
Клиент
Где применяется:
Отправка файлов по частям.
Отчёты, собираемые из нескольких частей.
Потоковое логирование от клиента на сервер.
#Java #middle #gRPC #proto
Теперь наоборот — клиент отправляет поток запросов, а сервер отвечает одним итоговым сообщением.
Клиент → (много запросов) → Сервер
Сервер → (один ответ) → Клиент
Это удобно, когда клиенту нужно собрать несколько событий или пакетов данных и отправить их вместе.
Пример .proto
service UploadService {
rpc UploadPhotos (stream PhotoChunk) returns (UploadStatus);
}
message PhotoChunk {
bytes content = 1;
}
message UploadStatus {
string message = 1;
}Сервер (Java)
public class UploadServiceImpl extends UploadServiceGrpc.UploadServiceImplBase {
@Override
public StreamObserver<PhotoChunk> uploadPhotos(StreamObserver<UploadStatus> responseObserver) {
return new StreamObserver<PhotoChunk>() {
int totalBytes = 0;
@Override
public void onNext(PhotoChunk chunk) {
totalBytes += chunk.getContent().size();
}
@Override
public void onError(Throwable t) {
System.err.println("Upload failed: " + t.getMessage());
}
@Override
public void onCompleted() {
UploadStatus status = UploadStatus.newBuilder()
.setMessage("Uploaded " + totalBytes + " bytes")
.build();
responseObserver.onNext(status);
responseObserver.onCompleted();
}
};
}
}Клиент
StreamObserver<PhotoChunk> requestObserver = asyncStub.uploadPhotos(
new StreamObserver<UploadStatus>() {
@Override
public void onNext(UploadStatus status) {
System.out.println(status.getMessage());
}
@Override
public void onError(Throwable t) {}
@Override
public void onCompleted() {}
}
);
// Отправляем несколько чанков
requestObserver.onNext(PhotoChunk.newBuilder().setContent(ByteString.copyFrom(new byte[1000])).build());
requestObserver.onNext(PhotoChunk.newBuilder().setContent(ByteString.copyFrom(new byte[500])).build());
requestObserver.onCompleted();
Где применяется:
Отправка файлов по частям.
Отчёты, собираемые из нескольких частей.
Потоковое логирование от клиента на сервер.
#Java #middle #gRPC #proto
👍2
4. Bidirectional Streaming RPC (двунаправленный поток)
Самый мощный и сложный тип.
Клиент и сервер одновременно отправляют данные потоками.
Они не ждут завершения друг друга — общение идёт асинхронно в обе стороны.
Клиент ⇄ (двунаправленный поток) ⇄ Сервер
Пример .proto
Сервер (Java)
Клиент
Где применяется:
Чаты и видеоконференции.
Онлайн-игры и взаимодействие в реальном времени.
Телеметрия, двунаправленные датчики, IoT.
Главная особенность: оба канала открыты, и клиент, и сервер могут посылать данные независимо друг от друга.
5. Под капотом
Все типы RPC работают поверх HTTP/2, где каждый поток — это отдельный канал в рамках одного TCP-соединения.
gRPC использует этот механизм для организации стримов.
По сути, StreamObserver в Java — это высокоуровневая абстракция над HTTP/2-стримом, обеспечивающая асинхронность и реактивное взаимодействие.
#Java #middle #gRPC #proto
Самый мощный и сложный тип.
Клиент и сервер одновременно отправляют данные потоками.
Они не ждут завершения друг друга — общение идёт асинхронно в обе стороны.
Клиент ⇄ (двунаправленный поток) ⇄ Сервер
Пример .proto
service ChatService {
rpc Chat (stream ChatMessage) returns (stream ChatMessage);
}
message ChatMessage {
string user = 1;
string text = 2;
}Сервер (Java)
public class ChatServiceImpl extends ChatServiceGrpc.ChatServiceImplBase {
@Override
public StreamObserver<ChatMessage> chat(StreamObserver<ChatMessage> responseObserver) {
return new StreamObserver<ChatMessage>() {
@Override
public void onNext(ChatMessage message) {
// Эхо-сообщение обратно клиенту
ChatMessage reply = ChatMessage.newBuilder()
.setUser("Server")
.setText("Echo: " + message.getText())
.build();
responseObserver.onNext(reply);
}
@Override
public void onError(Throwable t) {
System.err.println("Error: " + t.getMessage());
}
@Override
public void onCompleted() {
responseObserver.onCompleted();
}
};
}
}Клиент
StreamObserver<ChatMessage> requestObserver = asyncStub.chat(
new StreamObserver<ChatMessage>() {
@Override
public void onNext(ChatMessage value) {
System.out.println(value.getUser() + ": " + value.getText());
}
@Override
public void onError(Throwable t) {}
@Override
public void onCompleted() {}
}
);
requestObserver.onNext(ChatMessage.newBuilder().setUser("Client").setText("Hello!").build());
requestObserver.onNext(ChatMessage.newBuilder().setUser("Client").setText("How are you?").build());
requestObserver.onCompleted();
Где применяется:
Чаты и видеоконференции.
Онлайн-игры и взаимодействие в реальном времени.
Телеметрия, двунаправленные датчики, IoT.
Главная особенность: оба канала открыты, и клиент, и сервер могут посылать данные независимо друг от друга.
5. Под капотом
Все типы RPC работают поверх HTTP/2, где каждый поток — это отдельный канал в рамках одного TCP-соединения.
gRPC использует этот механизм для организации стримов.
По сути, StreamObserver в Java — это высокоуровневая абстракция над HTTP/2-стримом, обеспечивающая асинхронность и реактивное взаимодействие.
#Java #middle #gRPC #proto
👍3
gRPC в продакшене
1. Аутентификация и авторизация
gRPC изначально построен на HTTP/2, а значит поддерживает все стандартные механизмы шифрования и аутентификации, включая TLS/SSL.
На уровне протокола клиент и сервер могут обмениваться метаданными (headers), которые используются для передачи токенов, ключей или сессионных идентификаторов.
Аутентификация (authentication)
Аутентификация — это подтверждение личности клиента.
В gRPC это реализуется через метаданные (Metadata), которые добавляются к каждому запросу:
На стороне сервера этот токен можно проверить с помощью interceptor (см. ниже).
В корпоративных системах часто используются:
JWT (JSON Web Token) — стандартный формат токена.
mTLS (Mutual TLS) — двустороннее TLS-шифрование, где аутентифицируются обе стороны.
OAuth 2.0 — для интеграции с внешними провайдерами (Google, Auth0 и т.п.).
Авторизация (authorization)
После того как клиент прошёл аутентификацию, нужно проверить, имеет ли он право выполнять определённые действия.
Обычно авторизация реализуется на уровне interceptor’ов или бизнес-логики, где проверяются роли и права пользователя.
2. Interceptors — middleware для gRPC
Interceptors в gRPC выполняют ту же роль, что фильтры в Spring или middleware в Express.js.
Это промежуточные обработчики, которые могут:
логировать запросы и ответы;
измерять метрики;
проверять токены безопасности;
модифицировать контекст вызова;
перехватывать ошибки.
Пример серверного interceptor’а
Регистрируется interceptor при инициализации сервера:
Interceptors можно комбинировать — например, один для логирования, другой для метрик, третий для авторизации.
Это делает gRPC гибким и расширяемым.
#Java #middle #gRPC #proto
1. Аутентификация и авторизация
gRPC изначально построен на HTTP/2, а значит поддерживает все стандартные механизмы шифрования и аутентификации, включая TLS/SSL.
На уровне протокола клиент и сервер могут обмениваться метаданными (headers), которые используются для передачи токенов, ключей или сессионных идентификаторов.
Аутентификация (authentication)
Аутентификация — это подтверждение личности клиента.
В gRPC это реализуется через метаданные (Metadata), которые добавляются к каждому запросу:
// Пример Java-клиента с авторизационным токеном
ManagedChannel channel = ManagedChannelBuilder
.forAddress("localhost", 50051)
.useTransportSecurity()
.build();
CarServiceGrpc.CarServiceBlockingStub stub = CarServiceGrpc
.newBlockingStub(channel)
.withCallCredentials(new CallCredentials() {
@Override
public void applyRequestMetadata(
RequestInfo requestInfo, Executor executor, MetadataApplier applier) {
Metadata headers = new Metadata();
Metadata.Key<String> AUTHORIZATION =
Metadata.Key.of("Authorization", Metadata.ASCII_STRING_MARSHALLER);
headers.put(AUTHORIZATION, "Bearer my-secret-token");
applier.apply(headers);
}
});
На стороне сервера этот токен можно проверить с помощью interceptor (см. ниже).
В корпоративных системах часто используются:
JWT (JSON Web Token) — стандартный формат токена.
mTLS (Mutual TLS) — двустороннее TLS-шифрование, где аутентифицируются обе стороны.
OAuth 2.0 — для интеграции с внешними провайдерами (Google, Auth0 и т.п.).
Авторизация (authorization)
После того как клиент прошёл аутентификацию, нужно проверить, имеет ли он право выполнять определённые действия.
Обычно авторизация реализуется на уровне interceptor’ов или бизнес-логики, где проверяются роли и права пользователя.
2. Interceptors — middleware для gRPC
Interceptors в gRPC выполняют ту же роль, что фильтры в Spring или middleware в Express.js.
Это промежуточные обработчики, которые могут:
логировать запросы и ответы;
измерять метрики;
проверять токены безопасности;
модифицировать контекст вызова;
перехватывать ошибки.
Пример серверного interceptor’а
public class AuthInterceptor implements ServerInterceptor {
@Override
public <ReqT, RespT> ServerCall.Listener<ReqT> interceptCall(
ServerCall<ReqT, RespT> call,
Metadata headers,
ServerCallHandler<ReqT, RespT> next) {
String token = headers.get(Metadata.Key.of("Authorization", Metadata.ASCII_STRING_MARSHALLER));
if (token == null || !token.equals("Bearer my-secret-token")) {
call.close(Status.UNAUTHENTICATED.withDescription("Invalid token"), headers);
return new ServerCall.Listener<>() {}; // пустой listener
}
return next.startCall(call, headers);
}
}Регистрируется interceptor при инициализации сервера:
Server server = ServerBuilder
.forPort(50051)
.addService(ServerInterceptors.intercept(new CarServiceImpl(), new AuthInterceptor()))
.build()
.start();
Interceptors можно комбинировать — например, один для логирования, другой для метрик, третий для авторизации.
Это делает gRPC гибким и расширяемым.
#Java #middle #gRPC #proto
👍2
3. gRPC Gateway — REST-прокси для совместимости
Хотя gRPC эффективен, не все клиенты умеют с ним работать напрямую (например, браузеры без gRPC-Web).
Чтобы не дублировать API, используется gRPC Gateway — это HTTP-прокси, который преобразует REST-запросы в gRPC-вызовы.
Как это работает
Клиент делает обычный HTTP-запрос (GET, POST, PUT).
Gateway принимает запрос и преобразует его в бинарный gRPC-вызов.
Сервер gRPC обрабатывает его и возвращает ответ.
Gateway обратно конвертирует ответ в JSON.
Файл .proto содержит специальные аннотации:
Так создаётся REST-эндпоинт /v1/cars/{id}, который вызывает gRPC-метод GetCar.
gRPC Gateway позволяет сохранять одну кодовую базу и одну схему, но обслуживать и gRPC-, и REST-клиентов одновременно.
4. Балансировка нагрузки и мониторинг
gRPC поддерживает client-side load balancing, когда клиент сам выбирает, к какому серверу подключаться, используя список адресов.
Это особенно важно для микросервисов, где количество экземпляров сервиса динамически меняется.
Поддерживаются различные политики: round-robin, pick-first, weighted.
В Kubernetes это можно комбинировать с сервис-дискавери (через DNS или Consul).
Для продакшена жизненно важно собирать метрики.
gRPC интегрируется с Prometheus, OpenTelemetry, Zipkin, Jaeger для трассировки и мониторинга.
Через interceptors можно логировать время ответа, коды ошибок и нагрузку:
Трассировка (tracing) позволяет увидеть цепочку вызовов между микросервисами — от клиента до базы данных.
5. Совместимость версий и эволюция схем
Когда сервисы растут, .proto-файлы меняются.
Важно, чтобы новые версии клиента и сервера могли работать вместе без сбоев.
Для этого protobuf предоставляет правила совместимости.
Основные правила миграции
Не менять номера полей.
Каждое поле в message имеет уникальный номер, и именно он используется при сериализации.
Изменить имя поля можно, номер — нельзя.
Резервировать удалённые поля.
Если поле больше не используется, его нужно “зарезервировать”:
Это защищает от случайного переиспользования номеров или имён.
Добавлять новые поля безопасно.
Клиенты старых версий просто игнорируют незнакомые поля, сохраняя обратную совместимость.
Не менять тип данных существующих полей.
Например, int32 нельзя заменить на string.
Версионирование API
Часто версии отражаются в пакетах или namespace:
Так можно постепенно внедрять новые контракты без нарушения старых клиентов.
6. Как всё выглядит в продакшене
Реальная система на gRPC обычно включает:
Сервер с набором interceptor’ов (логирование, метрики, безопасность).
TLS-сертификаты и JWT-аутентификацию.
Балансировку через Kubernetes или сервис-дискавери.
Мониторинг и трассировку через OpenTelemetry.
gRPC Gateway для REST-клиентов.
CI/CD-пайплайн, генерирующий код по .proto и публикующий артефакты для разных языков.
#Java #middle #gRPC #proto
Хотя gRPC эффективен, не все клиенты умеют с ним работать напрямую (например, браузеры без gRPC-Web).
Чтобы не дублировать API, используется gRPC Gateway — это HTTP-прокси, который преобразует REST-запросы в gRPC-вызовы.
Как это работает
Клиент делает обычный HTTP-запрос (GET, POST, PUT).
Gateway принимает запрос и преобразует его в бинарный gRPC-вызов.
Сервер gRPC обрабатывает его и возвращает ответ.
Gateway обратно конвертирует ответ в JSON.
Файл .proto содержит специальные аннотации:
import "google/api/annotations.proto";
service CarService {
rpc GetCar(GetCarRequest) returns (CarResponse) {
option (google.api.http) = {
get: "/v1/cars/{id}"
};
}
}
Так создаётся REST-эндпоинт /v1/cars/{id}, который вызывает gRPC-метод GetCar.
gRPC Gateway позволяет сохранять одну кодовую базу и одну схему, но обслуживать и gRPC-, и REST-клиентов одновременно.
4. Балансировка нагрузки и мониторинг
gRPC поддерживает client-side load balancing, когда клиент сам выбирает, к какому серверу подключаться, используя список адресов.
Это особенно важно для микросервисов, где количество экземпляров сервиса динамически меняется.
Поддерживаются различные политики: round-robin, pick-first, weighted.
В Kubernetes это можно комбинировать с сервис-дискавери (через DNS или Consul).
ManagedChannel channel = ManagedChannelBuilder
.forTarget("dns:///my-grpc-service.default.svc.cluster.local")
.defaultLoadBalancingPolicy("round_robin")
.usePlaintext()
.build();
Для продакшена жизненно важно собирать метрики.
gRPC интегрируется с Prometheus, OpenTelemetry, Zipkin, Jaeger для трассировки и мониторинга.
Через interceptors можно логировать время ответа, коды ошибок и нагрузку:
long start = System.nanoTime();
RespT response = next.startCall(call, headers);
long duration = System.nanoTime() - start;
metrics.recordLatency(duration);
Трассировка (tracing) позволяет увидеть цепочку вызовов между микросервисами — от клиента до базы данных.
5. Совместимость версий и эволюция схем
Когда сервисы растут, .proto-файлы меняются.
Важно, чтобы новые версии клиента и сервера могли работать вместе без сбоев.
Для этого protobuf предоставляет правила совместимости.
Основные правила миграции
Не менять номера полей.
Каждое поле в message имеет уникальный номер, и именно он используется при сериализации.
Изменить имя поля можно, номер — нельзя.
Резервировать удалённые поля.
Если поле больше не используется, его нужно “зарезервировать”:
message Car {
reserved 4, 6 to 8;
reserved "old_model", "legacy_color";
}Это защищает от случайного переиспользования номеров или имён.
Добавлять новые поля безопасно.
Клиенты старых версий просто игнорируют незнакомые поля, сохраняя обратную совместимость.
Не менять тип данных существующих полей.
Например, int32 нельзя заменить на string.
Версионирование API
Часто версии отражаются в пакетах или namespace:
package car.v1;
service CarService { ... }
package car.v2;
service CarService { ... }
Так можно постепенно внедрять новые контракты без нарушения старых клиентов.
6. Как всё выглядит в продакшене
Реальная система на gRPC обычно включает:
Сервер с набором interceptor’ов (логирование, метрики, безопасность).
TLS-сертификаты и JWT-аутентификацию.
Балансировку через Kubernetes или сервис-дискавери.
Мониторинг и трассировку через OpenTelemetry.
gRPC Gateway для REST-клиентов.
CI/CD-пайплайн, генерирующий код по .proto и публикующий артефакты для разных языков.
#Java #middle #gRPC #proto
👍2
Что такое GraphQL и зачем он появился
Почему REST перестал устраивать и как Facebook придумал альтернативу
Современные приложения всё чаще строятся вокруг API.
Клиентам — будь то браузеры, мобильные приложения или IoT-устройства — нужны данные с сервера.
Долгое время стандартом для этого был REST, но со временем его ограничения стали очевидны.
Именно в ответ на эти ограничения в 2012 году в Facebook родился GraphQL — язык запросов для API, который изменил способ взаимодействия клиента и сервера.
1. Почему REST перестал всем подходить
REST долгое время считался идеальным способом построения API: простые URL, понятные методы (GET, POST, PUT, DELETE), формат JSON, читаемость.
Но со временем приложения стали сложнее, особенно на фронтенде.
Проблема 1: избыточные данные (overfetching).
REST-эндпоинт /users/42 возвращает всю информацию о пользователе — даже если на экране нужно только имя и аватар.
Клиент не может сказать серверу: “дай только эти два поля”.
В итоге трафик растёт, запросы замедляются, особенно на мобильных устройствах.
Проблема 2: недостаток данных (underfetching).
Обратная ситуация — когда данных не хватает.
Например, чтобы показать пользователя вместе с его постами и комментариями, REST-клиенту придётся сделать три запроса: /users/42, /users/42/posts, /posts/{id}/comments.
Каждый запрос — это отдельное соединение, время, накладные расходы.
Проблема 3: разные клиенты — разные потребности.
Мобильное приложение хочет меньше данных (экономия трафика), веб-клиент — больше.
REST вынуждает сервер создавать несколько версий эндпоинтов:
/users, /users/details, /users/short, и всё это быстро превращается в хаос.
Проблема 4: сложная эволюция.
Добавление новых полей или изменение структуры часто ломает старых клиентов.
Нужны версии: /v1/users, /v2/users, /v3/users.
С ростом проекта версионность превращается в отдельную боль.
Все эти проблемы — прямое следствие того, что REST навязывает структуру данных с серверной стороны.
Клиент получает то, что сервер решил вернуть.
GraphQL переворачивает это с ног на голову.
2. История появления GraphQL
GraphQL был создан внутри Facebook в 2012 году, когда компания столкнулась с резким ростом мобильных клиентов.
REST больше не справлялся: каждое обновление приложения требовало всё больше запросов к серверу, а мобильный интернет не прощал лишних килобайт.
Команда Facebook решила, что сервер не должен диктовать, какие данные возвращать.
Вместо этого клиент должен описывать свои потребности декларативно — “мне нужны вот такие данные, вот в такой структуре”.
В 2015 году Facebook открыл исходный код GraphQL, и он быстро стал стандартом в индустрии.
Сегодня его используют GitHub, Shopify, Twitter, Netflix, Pinterest, Airbnb и тысячи других компаний.
3. Основная идея GraphQL
Главная концепция GraphQL проста, но революционна:
клиент сам определяет, какие данные ему нужны.
Клиент не делает серию запросов к разным ресурсам, как в REST.
Он отправляет один запрос на сервер с точным описанием нужных полей, а сервер возвращает данные в том же формате.
Пример запроса:
Ответ сервера:
Клиент получает ровно то, что запросил — ни байта больше, ни меньше.
Больше нет проблемы overfetching или underfetching.
#Java #middle #GraphQL
Почему REST перестал устраивать и как Facebook придумал альтернативу
Современные приложения всё чаще строятся вокруг API.
Клиентам — будь то браузеры, мобильные приложения или IoT-устройства — нужны данные с сервера.
Долгое время стандартом для этого был REST, но со временем его ограничения стали очевидны.
Именно в ответ на эти ограничения в 2012 году в Facebook родился GraphQL — язык запросов для API, который изменил способ взаимодействия клиента и сервера.
1. Почему REST перестал всем подходить
REST долгое время считался идеальным способом построения API: простые URL, понятные методы (GET, POST, PUT, DELETE), формат JSON, читаемость.
Но со временем приложения стали сложнее, особенно на фронтенде.
Проблема 1: избыточные данные (overfetching).
REST-эндпоинт /users/42 возвращает всю информацию о пользователе — даже если на экране нужно только имя и аватар.
Клиент не может сказать серверу: “дай только эти два поля”.
В итоге трафик растёт, запросы замедляются, особенно на мобильных устройствах.
Проблема 2: недостаток данных (underfetching).
Обратная ситуация — когда данных не хватает.
Например, чтобы показать пользователя вместе с его постами и комментариями, REST-клиенту придётся сделать три запроса: /users/42, /users/42/posts, /posts/{id}/comments.
Каждый запрос — это отдельное соединение, время, накладные расходы.
Проблема 3: разные клиенты — разные потребности.
Мобильное приложение хочет меньше данных (экономия трафика), веб-клиент — больше.
REST вынуждает сервер создавать несколько версий эндпоинтов:
/users, /users/details, /users/short, и всё это быстро превращается в хаос.
Проблема 4: сложная эволюция.
Добавление новых полей или изменение структуры часто ломает старых клиентов.
Нужны версии: /v1/users, /v2/users, /v3/users.
С ростом проекта версионность превращается в отдельную боль.
Все эти проблемы — прямое следствие того, что REST навязывает структуру данных с серверной стороны.
Клиент получает то, что сервер решил вернуть.
GraphQL переворачивает это с ног на голову.
2. История появления GraphQL
GraphQL был создан внутри Facebook в 2012 году, когда компания столкнулась с резким ростом мобильных клиентов.
REST больше не справлялся: каждое обновление приложения требовало всё больше запросов к серверу, а мобильный интернет не прощал лишних килобайт.
Команда Facebook решила, что сервер не должен диктовать, какие данные возвращать.
Вместо этого клиент должен описывать свои потребности декларативно — “мне нужны вот такие данные, вот в такой структуре”.
В 2015 году Facebook открыл исходный код GraphQL, и он быстро стал стандартом в индустрии.
Сегодня его используют GitHub, Shopify, Twitter, Netflix, Pinterest, Airbnb и тысячи других компаний.
3. Основная идея GraphQL
Главная концепция GraphQL проста, но революционна:
клиент сам определяет, какие данные ему нужны.
Клиент не делает серию запросов к разным ресурсам, как в REST.
Он отправляет один запрос на сервер с точным описанием нужных полей, а сервер возвращает данные в том же формате.
Пример запроса:
query {
user(id: 42) {
name
avatar
posts(limit: 3) {
title
likes
}
}
}Ответ сервера:
{
"data": {
"user": {
"name": "Den",
"avatar": "https://example.com/den.jpg",
"posts": [
{ "title": "gRPC и Java", "likes": 120 },
{ "title": "GraphQL под капотом", "likes": 80 },
{ "title": "Spring Boot и микросервисы", "likes": 95 }
]
}
}
}Клиент получает ровно то, что запросил — ни байта больше, ни меньше.
Больше нет проблемы overfetching или underfetching.
#Java #middle #GraphQL
👍3
4. Как это работает
В GraphQL всё держится на схеме (schema).
Она описывает, какие типы данных доступны, какие поля у них есть и какие операции разрешены.
Пример схемы:
GraphQL строго типизирован.
Клиент знает, какие поля доступны и какого они типа, а сервер может валидировать запрос до его выполнения.
5. Ключевые преимущества GraphQL
1. Гибкость запросов
Клиент формирует запрос под себя:
на мобильном — только name и avatar,
в вебе — name, posts, comments.
Сервер не меняется, меняется лишь запрос.
2. Один запрос — много данных
GraphQL позволяет собрать связанные сущности за один вызов.
В REST для этого нужно было несколько запросов, теперь достаточно одного.
3. Строгая типизация
Схема описана декларативно, и клиент может проверять запросы ещё до выполнения.
Ошибки, вроде “такого поля нет” или “тип не совпадает”, ловятся на этапе компиляции.
4. Эволюция без версий
GraphQL не требует /v1, /v2, /v3.
Добавил поле — клиенты, которые его не запрашивают, даже не заметят изменений.
Старые клиенты продолжают работать, новые используют расширенные возможности.
5. Самодокументируемость
GraphQL-сервер знает всю структуру данных.
Это позволяет автоматически генерировать документацию и визуальные IDE вроде GraphiQL или Apollo Sandbox, где можно исследовать схему и писать запросы интерактивно.
6. Почему GraphQL особенно популярен во фронтенде
Фронтенд-разработка — динамичная среда:
разные страницы требуют разные наборы данных, часто меняются требования, нужны быстрые итерации.
GraphQL идеально вписывается в этот процесс, потому что:
Разработчик фронтенда сам решает, какие поля ему нужны.
Не нужно ждать, пока backend добавит новый эндпоинт.
Данные приходят в предсказуемом виде, строго по типам.
Поддерживаются инструменты вроде Apollo Client или Relay, которые кэшируют и синхронизируют данные автоматически.
Именно поэтому GraphQL сегодня стал де-факто стандартом для фронтенд-команд крупных проектов.
REST чаще используется для внешних публичных API, gRPC — для связи микросервисов,
а GraphQL стал интерфейсом между фронтом и внутренним миром данных.
#Java #middle #GraphQL
В GraphQL всё держится на схеме (schema).
Она описывает, какие типы данных доступны, какие поля у них есть и какие операции разрешены.
Пример схемы:
type User {
id: ID!
name: String!
avatar: String
posts(limit: Int): [Post]
}
type Post {
id: ID!
title: String!
likes: Int!
}
type Query {
user(id: ID!): User
}
type — описание структуры данных, аналог класса в Java.
Query — “входная точка”, через которую клиент получает данные.
! — обязательное поле.
[Post] — список постов.GraphQL строго типизирован.
Клиент знает, какие поля доступны и какого они типа, а сервер может валидировать запрос до его выполнения.
5. Ключевые преимущества GraphQL
1. Гибкость запросов
Клиент формирует запрос под себя:
на мобильном — только name и avatar,
в вебе — name, posts, comments.
Сервер не меняется, меняется лишь запрос.
2. Один запрос — много данных
GraphQL позволяет собрать связанные сущности за один вызов.
В REST для этого нужно было несколько запросов, теперь достаточно одного.
3. Строгая типизация
Схема описана декларативно, и клиент может проверять запросы ещё до выполнения.
Ошибки, вроде “такого поля нет” или “тип не совпадает”, ловятся на этапе компиляции.
4. Эволюция без версий
GraphQL не требует /v1, /v2, /v3.
Добавил поле — клиенты, которые его не запрашивают, даже не заметят изменений.
Старые клиенты продолжают работать, новые используют расширенные возможности.
5. Самодокументируемость
GraphQL-сервер знает всю структуру данных.
Это позволяет автоматически генерировать документацию и визуальные IDE вроде GraphiQL или Apollo Sandbox, где можно исследовать схему и писать запросы интерактивно.
6. Почему GraphQL особенно популярен во фронтенде
Фронтенд-разработка — динамичная среда:
разные страницы требуют разные наборы данных, часто меняются требования, нужны быстрые итерации.
GraphQL идеально вписывается в этот процесс, потому что:
Разработчик фронтенда сам решает, какие поля ему нужны.
Не нужно ждать, пока backend добавит новый эндпоинт.
Данные приходят в предсказуемом виде, строго по типам.
Поддерживаются инструменты вроде Apollo Client или Relay, которые кэшируют и синхронизируют данные автоматически.
Именно поэтому GraphQL сегодня стал де-факто стандартом для фронтенд-команд крупных проектов.
REST чаще используется для внешних публичных API, gRPC — для связи микросервисов,
а GraphQL стал интерфейсом между фронтом и внутренним миром данных.
#Java #middle #GraphQL
👍4
Архитектура и принципы работы GraphQL
Что происходит между клиентом, схемой и источниками данных
1. Главная идея архитектуры
GraphQL-сервер — это прослойка, которая принимает декларативные запросы, проверяет их на соответствие схеме, исполняет нужные резолверы и возвращает результат.
Он не хранит данные сам по себе.
GraphQL — это не база данных, а универсальный интерфейс к любому источнику данных: SQL, NoSQL, микросервисы, REST, файлы, внешние API.
Его задача — связать клиентскую структуру запроса со структурой данных в бэкенде.
Схематично:
Клиент → GraphQL сервер → Источники данных (DB, REST, gRPC, API)
2. Schema — сердце GraphQL
Schema (схема) — это основной контракт между клиентом и сервером.
Она описывает:
какие данные доступны;
какие поля у этих данных есть;
какие операции можно выполнять.
Схема написана на SDL (Schema Definition Language), декларативном языке, напоминающем описание классов.
Пример:
Ключевые понятия:
type — определяет структуру данных (аналог Java-класса или DTO).
! — обязательное поле (non-null).
[User!]! — список пользователей, где ни один элемент не равен null.
Query — специальный тип, описывающий операции чтения.
Схема — это не код, а декларация.
На её основе GraphQL сервер автоматически понимает, как валидировать запросы, какие поля допустимы и какие возвращать ошибки.
3. Query, Mutation, Subscription — три типа операций
GraphQL разделяет все действия на три категории.
1. Query — запрос данных (аналог GET в REST)
Используется для чтения.
Клиент описывает, какие сущности и поля нужны:
Сервер вернёт данные в том же формате:
2. Mutation — изменение данных (аналог POST/PUT/DELETE)
Mutation обозначает действия, которые модифицируют состояние системы.
Они могут создавать, обновлять или удалять записи.
GraphQL возвращает результат — обновлённые данные или подтверждение операции.
3. Subscription — подписка на события (реактивный поток)
Subscription создаёт постоянное соединение между клиентом и сервером (обычно через WebSocket).
Когда на сервере происходят изменения, клиент получает уведомления в реальном времени.
Если на сервере создан новый пользователь, событие userCreated автоматически отправляется всем подписанным клиентам.
4. Как работает запрос GraphQL: путь от клиента до данных
Чтобы понять механику, посмотрим на полный цикл обработки запроса.
Шаг 1. Клиент отправляет запрос
Клиент (например, браузер) отправляет HTTP POST на /graphql с JSON-телом:
Шаг 2. Сервер парсит и валидирует запрос
GraphQL-сервер:
Парсит текст запроса.
Проверяет, что все поля и типы существуют в схеме.
Проверяет типы аргументов (id действительно ID!).
Отклоняет запрос, если нарушен контракт схемы.
Таким образом, сервер никогда не выполнит запрос, который не соответствует схеме.
Это гарантирует типобезопасность и предсказуемость работы.
#Java #middle #GraphQL
Что происходит между клиентом, схемой и источниками данных
1. Главная идея архитектуры
GraphQL-сервер — это прослойка, которая принимает декларативные запросы, проверяет их на соответствие схеме, исполняет нужные резолверы и возвращает результат.
Он не хранит данные сам по себе.
GraphQL — это не база данных, а универсальный интерфейс к любому источнику данных: SQL, NoSQL, микросервисы, REST, файлы, внешние API.
Его задача — связать клиентскую структуру запроса со структурой данных в бэкенде.
Схематично:
Клиент → GraphQL сервер → Источники данных (DB, REST, gRPC, API)
2. Schema — сердце GraphQL
Schema (схема) — это основной контракт между клиентом и сервером.
Она описывает:
какие данные доступны;
какие поля у этих данных есть;
какие операции можно выполнять.
Схема написана на SDL (Schema Definition Language), декларативном языке, напоминающем описание классов.
Пример:
type User {
id: ID!
name: String!
posts: [Post!]!
}
type Post {
id: ID!
title: String!
content: String
}
type Query {
user(id: ID!): User
allUsers: [User!]!
}Ключевые понятия:
type — определяет структуру данных (аналог Java-класса или DTO).
! — обязательное поле (non-null).
[User!]! — список пользователей, где ни один элемент не равен null.
Query — специальный тип, описывающий операции чтения.
Схема — это не код, а декларация.
На её основе GraphQL сервер автоматически понимает, как валидировать запросы, какие поля допустимы и какие возвращать ошибки.
3. Query, Mutation, Subscription — три типа операций
GraphQL разделяет все действия на три категории.
1. Query — запрос данных (аналог GET в REST)
Используется для чтения.
Клиент описывает, какие сущности и поля нужны:
query {
user(id: 42) {
name
posts {
title
}
}
}Сервер вернёт данные в том же формате:
{
"data": {
"user": {
"name": "Den",
"posts": [
{ "title": "gRPC и Java" },
{ "title": "GraphQL под капотом" }
]
}
}
}2. Mutation — изменение данных (аналог POST/PUT/DELETE)
Mutation обозначает действия, которые модифицируют состояние системы.
Они могут создавать, обновлять или удалять записи.
mutation {
createUser(input: { name: "Alex" }) {
id
name
}
}GraphQL возвращает результат — обновлённые данные или подтверждение операции.
3. Subscription — подписка на события (реактивный поток)
Subscription создаёт постоянное соединение между клиентом и сервером (обычно через WebSocket).
Когда на сервере происходят изменения, клиент получает уведомления в реальном времени.
subscription {
userCreated {
id
name
}
}Если на сервере создан новый пользователь, событие userCreated автоматически отправляется всем подписанным клиентам.
4. Как работает запрос GraphQL: путь от клиента до данных
Чтобы понять механику, посмотрим на полный цикл обработки запроса.
Шаг 1. Клиент отправляет запрос
Клиент (например, браузер) отправляет HTTP POST на /graphql с JSON-телом:
{
"query": "query { user(id: 42) { name posts { title } } }"
}
GraphQL-запрос — это декларативное описание структуры данных, не код и не SQL.Шаг 2. Сервер парсит и валидирует запрос
GraphQL-сервер:
Парсит текст запроса.
Проверяет, что все поля и типы существуют в схеме.
Проверяет типы аргументов (id действительно ID!).
Отклоняет запрос, если нарушен контракт схемы.
Таким образом, сервер никогда не выполнит запрос, который не соответствует схеме.
Это гарантирует типобезопасность и предсказуемость работы.
#Java #middle #GraphQL
👍1
Шаг 3. Сервер вызывает резолверы
Резолвер (resolver) — это функция, которая знает, как получить данные для конкретного поля.
Например, в Java через библиотеку graphql-java:
Резолверы вызываются рекурсивно:
Сначала выполняется user(id: 42).
Затем для каждого пользователя — posts.
Затем для каждого поста — title.
GraphQL умеет оптимизировать выполнение: например, группировать одинаковые вызовы (DataLoader паттерн).
Шаг 4. Формирование ответа
После выполнения всех резолверов GraphQL собирает результат в структуру, повторяющую форму запроса, и отправляет JSON-ответ клиенту:
Если на каком-то шаге произошла ошибка, она не прерывает всё выполнение.
GraphQL вернёт частичные данные + список ошибок:
5. Почему GraphQL — не база данных
Эта путаница встречается часто.
GraphQL не хранит и не управляет данными.
Он не заменяет SQL или ORM.
GraphQL — это API-уровень, который:
принимает запросы,
интерпретирует их,
вызывает нужные источники данных,
собирает и возвращает результат в едином формате.
Под капотом это может быть:
JDBC-запросы в PostgreSQL,
вызовы REST API других микросервисов,
gRPC-вызовы,
кэш Redis,
файловая система или внешние API.
GraphQL — унифицированный интерфейс доступа к любым данным, независимо от их источника.
6. Интеграция GraphQL в бэкенд
GraphQL не заменяет ваш backend — он становится поверх него.
В Java это обычно выглядит так:
Spring Boot + graphql-spring-boot-starter — стандартный способ поднять GraphQL-сервер.
Схема (.graphqls) описывается декларативно.
Резолверы реализуются как обычные Spring-бины.
Пример:
GraphQL сам вызывает нужный метод в зависимости от запроса клиента.
Таким образом, GraphQL интегрируется поверх существующего слоя сервисов и репозиториев, не требуя переписывания бизнес-логики.
#Java #middle #GraphQL
Резолвер (resolver) — это функция, которая знает, как получить данные для конкретного поля.
Например, в Java через библиотеку graphql-java:
GraphQLObjectType userType = newObject()
.name("User")
.field(field -> field
.name("id")
.type(Scalars.GraphQLID))
.field(field -> field
.name("name")
.type(Scalars.GraphQLString))
.field(field -> field
.name("posts")
.type(new GraphQLList(postType))
.dataFetcher(env -> postService.getByUser(env.getSource())))
.build();
Резолверы вызываются рекурсивно:
Сначала выполняется user(id: 42).
Затем для каждого пользователя — posts.
Затем для каждого поста — title.
GraphQL умеет оптимизировать выполнение: например, группировать одинаковые вызовы (DataLoader паттерн).
Шаг 4. Формирование ответа
После выполнения всех резолверов GraphQL собирает результат в структуру, повторяющую форму запроса, и отправляет JSON-ответ клиенту:
{
"data": {
"user": {
"name": "Den",
"posts": [{ "title": "gRPC и Java" }]
}
}
}Если на каком-то шаге произошла ошибка, она не прерывает всё выполнение.
GraphQL вернёт частичные данные + список ошибок:
{
"data": { "user": null },
"errors": [{ "message": "User not found" }]
}5. Почему GraphQL — не база данных
Эта путаница встречается часто.
GraphQL не хранит и не управляет данными.
Он не заменяет SQL или ORM.
GraphQL — это API-уровень, который:
принимает запросы,
интерпретирует их,
вызывает нужные источники данных,
собирает и возвращает результат в едином формате.
Под капотом это может быть:
JDBC-запросы в PostgreSQL,
вызовы REST API других микросервисов,
gRPC-вызовы,
кэш Redis,
файловая система или внешние API.
GraphQL — унифицированный интерфейс доступа к любым данным, независимо от их источника.
6. Интеграция GraphQL в бэкенд
GraphQL не заменяет ваш backend — он становится поверх него.
В Java это обычно выглядит так:
Spring Boot + graphql-spring-boot-starter — стандартный способ поднять GraphQL-сервер.
Схема (.graphqls) описывается декларативно.
Резолверы реализуются как обычные Spring-бины.
Пример:
@Component
public class UserResolver implements GraphQLQueryResolver {
private final UserService userService;
public UserResolver(UserService userService) { this.userService = userService; }
public User user(Long id) {
return userService.findById(id);
}
public List<User> allUsers() {
return userService.findAll();
}
}
GraphQL сам вызывает нужный метод в зависимости от запроса клиента.
Таким образом, GraphQL интегрируется поверх существующего слоя сервисов и репозиториев, не требуя переписывания бизнес-логики.
#Java #middle #GraphQL
👍1
Определение схемы в GraphQL (SDL)
SDL (Schema Definition Language) — это декларативный язык описания GraphQL-схем.
Он задаёт структуру данных и операций, доступных клиенту.
SDL не содержит логики — это контракт, который определяет «форму» API: какие типы есть, какие поля у них доступны, какие аргументы принимаются.
GraphQL-сервер использует SDL как единый источник правды для валидации запросов и построения выполнения.
1. Основные виды типов в SDL
GraphQL предоставляет несколько видов типов, каждый из которых отвечает за свою роль.
1. type — объектный тип (основа схемы)
Используется для описания сущностей:
2. input — тип вводимых данных
Используется для аргументов мутаций или сложных параметров запросов.
Отличается от type тем, что не может содержать резолверов и нельзя ссылаться на type с циклом.
3. enum — перечисления
Хороший способ ограничить варианты.
4. interface — абстрактный тип
Позволяет описывать общий контракт нескольких типов.
5. union — объединение разных типов
Не имеет общих полей.
Используется, когда ответ может быть разным по структуре.
2. Как выглядит схема GraphQL
В GraphQL схема определяется набором корневых операций:
Query — чтение
Mutation — изменение
Subscription — события/стриминг
Пример минимальной структуры:
На практике «schema {}» часто опускают — сервер выводит её автоматически.
3. Полный пример схемы: пользователи, посты и комментарии
Ниже — типичная схема блог-платформы, написанная в чистом SDL.
#Java #middle #GraphQL
SDL (Schema Definition Language) — это декларативный язык описания GraphQL-схем.
Он задаёт структуру данных и операций, доступных клиенту.
SDL не содержит логики — это контракт, который определяет «форму» API: какие типы есть, какие поля у них доступны, какие аргументы принимаются.
GraphQL-сервер использует SDL как единый источник правды для валидации запросов и построения выполнения.
1. Основные виды типов в SDL
GraphQL предоставляет несколько видов типов, каждый из которых отвечает за свою роль.
1. type — объектный тип (основа схемы)
Используется для описания сущностей:
type User {
id: ID!
name: String!
posts: [Post!]!
}
Типы описывают структуру данных — аналог классов/DTO.2. input — тип вводимых данных
Используется для аргументов мутаций или сложных параметров запросов.
Отличается от type тем, что не может содержать резолверов и нельзя ссылаться на type с циклом.
input CreateUserInput {
name: String!
age: Int
}3. enum — перечисления
Хороший способ ограничить варианты.
enum Role {
ADMIN
USER
GUEST
}4. interface — абстрактный тип
Позволяет описывать общий контракт нескольких типов.
interface Entity {
id: ID!
}
type User implements Entity {
id: ID!
name: String!
}
type Post implements Entity {
id: ID!
title: String!
}
Клиент может запросить id для любого, кто реализует Entity.5. union — объединение разных типов
Не имеет общих полей.
Используется, когда ответ может быть разным по структуре.
union SearchResult = User | Post | Comment
2. Как выглядит схема GraphQL
В GraphQL схема определяется набором корневых операций:
Query — чтение
Mutation — изменение
Subscription — события/стриминг
Пример минимальной структуры:
schema {
query: Query
mutation: Mutation
}На практике «schema {}» часто опускают — сервер выводит её автоматически.
3. Полный пример схемы: пользователи, посты и комментарии
Ниже — типичная схема блог-платформы, написанная в чистом SDL.
Сущности
type User {
id: ID!
name: String!
role: Role!
posts: [Post!]!
}
type Post {
id: ID!
title: String!
content: String
author: User!
comments: [Comment!]!
}
type Comment {
id: ID!
text: String!
author: User!
}
Перечисления
enum Role {
ADMIN
USER
GUEST
}
Входные данные
input CreatePostInput {
title: String!
content: String
}
Запросы
type Query {
user(id: ID!): User
users: [User!]!
post(id: ID!): Post
posts(limit: Int, authorId: ID): [Post!]!
}
Мутации
type Mutation {
createPost(input: CreatePostInput!): Post!
deletePost(id: ID!): Boolean!
}
Подписки
type Subscription {
postCreated: Post!
}
#Java #middle #GraphQL
👍3
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