Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2 1
История IT-технологий сегодня — 01 декабря
ℹ️ Кто родился в этот день
Корнелиус Шумахер (нем. Cornelius Schumacher; род. 1 декабря 1969, Тюбинген, Германия) — немецкий разработчик свободного ПО, активист свободного софта, внёс вклад в KDE — популярную среду рабочего стола для GNU/Linux.
🌐 Знаковые события
1677— состоялся запуск первой в мире коммерческой системы интерактивного кабельного телевидения в Колумбусе (Огайо, США). Система предлагала порядка 30 каналов, из которых часть были обычными вещательными, часть — платными (pay-per-view), а часть — интерактивными, с возможностью «обратной связи» пользователя через пульт.
#Biography #Birth_Date #Events #01Декабря
Корнелиус Шумахер (нем. Cornelius Schumacher; род. 1 декабря 1969, Тюбинген, Германия) — немецкий разработчик свободного ПО, активист свободного софта, внёс вклад в KDE — популярную среду рабочего стола для GNU/Linux.
1677— состоялся запуск первой в мире коммерческой системы интерактивного кабельного телевидения в Колумбусе (Огайо, США). Система предлагала порядка 30 каналов, из которых часть были обычными вещательными, часть — платными (pay-per-view), а часть — интерактивными, с возможностью «обратной связи» пользователя через пульт.
#Biography #Birth_Date #Events #01Декабря
Please open Telegram to view this post
VIEW IN TELEGRAM
Advanced GraphQL: реактивность и Federation
GraphQL уже давно не ограничивается статическими запросами к одной базе.
Современные системы требуют:
реактивности: live updates, push-события на фронтенд;
масштабируемости: объединение схем из разных сервисов;
микросервисной интеграции: разные источники данных и форматы;
единый клиентский интерфейс: фронт видит единую схему, хотя данные приходят из нескольких микросервисов.
Эти задачи решаются через Subscriptions, Federation, Schema Stitching, GraphQL Gateway.
1. Subscriptions и live updates
1.1 Что такое Subscription
Subscription — это тип операции GraphQL, который подписывается на события и получает данные по мере их появления, в отличие от Query/Mutation, где данные запрашиваются один раз.
Используется для:
чатов и уведомлений;
реального мониторинга (метрики, логи);
обновления UI при изменении данных на сервере.
1.2 Механика на сервере
Клиент подписывается на событие через WebSocket или Server-Sent Events (SSE).
Сервер регистрирует подписку и хранит её в памяти или через pub/sub (Redis, Kafka).
При событии вызываются соответствующие резолверы Subscription, результат отправляется клиенту.
1.3 Пример на Spring Boot с graphql-java
Схема (schema.graphqls)
Резолвер Subscription
Публикация события (например, после мутации)
1.4 Реактивная интеграция с gRPC
Микросервис может уведомлять GraphQL через gRPC стриминг (Server Streaming).
GraphQL Gateway принимает события и пушит их клиентам через Subscription.
Реализуется через Publisher или Flux (Project Reactor) в Java.
Пример с Project Reactor:
#Java #middle #GraphQL
GraphQL уже давно не ограничивается статическими запросами к одной базе.
Современные системы требуют:
реактивности: live updates, push-события на фронтенд;
масштабируемости: объединение схем из разных сервисов;
микросервисной интеграции: разные источники данных и форматы;
единый клиентский интерфейс: фронт видит единую схему, хотя данные приходят из нескольких микросервисов.
Эти задачи решаются через Subscriptions, Federation, Schema Stitching, GraphQL Gateway.
1. Subscriptions и live updates
1.1 Что такое Subscription
Subscription — это тип операции GraphQL, который подписывается на события и получает данные по мере их появления, в отличие от Query/Mutation, где данные запрашиваются один раз.
Используется для:
чатов и уведомлений;
реального мониторинга (метрики, логи);
обновления UI при изменении данных на сервере.
1.2 Механика на сервере
Клиент подписывается на событие через WebSocket или Server-Sent Events (SSE).
Сервер регистрирует подписку и хранит её в памяти или через pub/sub (Redis, Kafka).
При событии вызываются соответствующие резолверы Subscription, результат отправляется клиенту.
1.3 Пример на Spring Boot с graphql-java
Схема (schema.graphqls)
type Subscription {
postAdded: Post!
}Резолвер Subscription
@Component
public class PostSubscription implements GraphQLSubscriptionResolver {
private final Publisher<Post> postPublisher;
public PostSubscription(Publisher<Post> postPublisher) {
this.postPublisher = postPublisher;
}
public Publisher<Post> postAdded() {
return postPublisher;
}
}
Публикация события (например, после мутации)
@Component
public class PostMutation implements GraphQLMutationResolver {
private final Publisher<Post> postPublisher;
private final PostService postService;
public PostMutation(PostService postService, Publisher<Post> postPublisher) {
this.postService = postService;
this.postPublisher = postPublisher;
}
public Post createPost(CreatePostInput input) {
Post newPost = postService.create(input);
postPublisher.publish(newPost); // пушим в подписчиков
return newPost;
}
}
Таким образом фронтенд автоматически получает новые посты без повторных запросов.
1.4 Реактивная интеграция с gRPC
Микросервис может уведомлять GraphQL через gRPC стриминг (Server Streaming).
GraphQL Gateway принимает события и пушит их клиентам через Subscription.
Реализуется через Publisher или Flux (Project Reactor) в Java.
Пример с Project Reactor:
public Publisher<Post> postAdded() {
return Flux.from(postGrpcStub.subscribePosts());
}#Java #middle #GraphQL
👍1
2. Federation / Schema stitching
2.1 Зачем нужна Federation
В микросервисной архитектуре каждая команда может иметь свой GraphQL-сервис.
Фронтенду нужен единый endpoint, а не десятки отдельных.
Schema stitching: объединяет схемы в один endpoint вручную.
Apollo Federation: более продвинутый стандарт, позволяющий каждому сервису быть федеративным узлом.
2.2 Принцип работы Federation
Subgraph Service — каждый сервис предоставляет свою часть схемы: User, Post, Comment.
Gateway / Apollo Gateway — объединяет схемы subgraph и решает, какой сервис вызывать для каждого запроса.
Reference resolver — позволяет связать типы из разных сервисов (например, User в Post).
Пример на Java (с Spring Boot + GraphQL Federation, библиотека graphql-java-federation):
Сервис Users
Сервис Posts
Java resolver для Post.author
3. GraphQL Gateway и объединение данных
3.1 Роль Gateway
Аггрегирует данные из нескольких микросервисов (REST, gRPC, базы, Kafka).
Решает проблемы N+1 через batching (DataLoader).
Управляет кешированием и throttling.
Поддерживает Subscriptions и Federation.
3.2 Пример архитектуры
Особенности:
Gateway использует DataLoader для агрегации запросов, уменьшения количества вызовов к сервисам.
Subscriptions могут получать события из gRPC стримов или Kafka и пушить клиенту.
4. Примеры использования и кейсы
4.1 Live feed
Мобильное приложение подписывается на postAdded.
PostService пушит новые посты через gRPC или внутренний EventBus.
Gateway трансформирует данные в GraphQL Subscription → клиент получает обновления моментально.
4.2 Микросервисная интеграция
UserService и PostService разрабатываются разными командами.
Gateway объединяет их схемы через Federation.
Фронтенд видит единый API: user(id: 1) { name posts { title } }, не зная, что posts приходит из другого сервиса.
4.3 Agreggation + caching
Gateway кеширует данные User на 5 минут.
PostService вызывается только для новых постов.
DataLoader агрегирует все запросы к UserService за одну операцию.
5. Лучшие практики
Использовать Federation для масштабируемых командных проектов.
Subscription через WebSocket + Publisher/Flux для реактивных интерфейсов.
DataLoader для оптимизации N+1 вызовов в распределённых сервисах.
Разделять ответственность: микросервисы предоставляют свои типы и резолверы, Gateway агрегирует.
Event-driven подход для live updates: gRPC streaming, Kafka, Redis Pub/Sub.
Мониторинг: трассировка на уровне каждого subgraph, latency, throughput.
Эволюция схем: добавление новых полей без ломки клиентов, депрекация старых.
#Java #middle #GraphQL
2.1 Зачем нужна Federation
В микросервисной архитектуре каждая команда может иметь свой GraphQL-сервис.
Фронтенду нужен единый endpoint, а не десятки отдельных.
Schema stitching: объединяет схемы в один endpoint вручную.
Apollo Federation: более продвинутый стандарт, позволяющий каждому сервису быть федеративным узлом.
2.2 Принцип работы Federation
Subgraph Service — каждый сервис предоставляет свою часть схемы: User, Post, Comment.
Gateway / Apollo Gateway — объединяет схемы subgraph и решает, какой сервис вызывать для каждого запроса.
Reference resolver — позволяет связать типы из разных сервисов (например, User в Post).
Пример на Java (с Spring Boot + GraphQL Federation, библиотека graphql-java-federation):
Сервис Users
type User @key(fields: "id") {
id: ID!
name: String!
}Сервис Posts
type Post {
id: ID!
title: String!
author: User @provides(fields: "name")
}Java resolver для Post.author
@Component
public class PostResolver implements GraphQLResolver<Post> {
private final UserGrpc.UserBlockingStub userStub;
public PostResolver(UserGrpc.UserBlockingStub userStub) {
this.userStub = userStub;
}
public User author(Post post) {
UserRequest req = UserRequest.newBuilder().setId(post.getAuthorId()).build();
UserResponse resp = userStub.getUser(req);
return mapToGraphQLUser(resp);
}
}
Gateway собирает всю федеративную схему и возвращает фронтенду единый API.
3. GraphQL Gateway и объединение данных
3.1 Роль Gateway
Аггрегирует данные из нескольких микросервисов (REST, gRPC, базы, Kafka).
Решает проблемы N+1 через batching (DataLoader).
Управляет кешированием и throttling.
Поддерживает Subscriptions и Federation.
3.2 Пример архитектуры
[Frontend SPA / Mobile] --GraphQL--> [GraphQL Gateway] --gRPC--> [UserService]
|--> [PostService]
|--> [CommentService]
|--> [External REST API]
Особенности:
Gateway использует DataLoader для агрегации запросов, уменьшения количества вызовов к сервисам.
Subscriptions могут получать события из gRPC стримов или Kafka и пушить клиенту.
4. Примеры использования и кейсы
4.1 Live feed
Мобильное приложение подписывается на postAdded.
PostService пушит новые посты через gRPC или внутренний EventBus.
Gateway трансформирует данные в GraphQL Subscription → клиент получает обновления моментально.
4.2 Микросервисная интеграция
UserService и PostService разрабатываются разными командами.
Gateway объединяет их схемы через Federation.
Фронтенд видит единый API: user(id: 1) { name posts { title } }, не зная, что posts приходит из другого сервиса.
4.3 Agreggation + caching
Gateway кеширует данные User на 5 минут.
PostService вызывается только для новых постов.
DataLoader агрегирует все запросы к UserService за одну операцию.
5. Лучшие практики
Использовать Federation для масштабируемых командных проектов.
Subscription через WebSocket + Publisher/Flux для реактивных интерфейсов.
DataLoader для оптимизации N+1 вызовов в распределённых сервисах.
Разделять ответственность: микросервисы предоставляют свои типы и резолверы, Gateway агрегирует.
Event-driven подход для live updates: gRPC streaming, Kafka, Redis Pub/Sub.
Мониторинг: трассировка на уровне каждого subgraph, latency, throughput.
Эволюция схем: добавление новых полей без ломки клиентов, депрекация старых.
#Java #middle #GraphQL
👍1
Что выведет код?
#Tasks
import java.util.Optional;
public class Task011225 {
public static void main(String[] args) {
Optional<String> emptyOpt = Optional.empty();
Optional<String> valueOpt = Optional.of("hello");
Optional<String> nullOpt = Optional.ofNullable(null);
System.out.println(valueOpt.get());
System.out.println(nullOpt.isPresent());
System.out.println(emptyOpt.isPresent());
System.out.println(emptyOpt.get());
}
}
#Tasks
Варианты ответа:
Anonymous Quiz
43%
hello false false исключение
43%
hello true false null
0%
hello false false null
14%
hello true true исключение
Вопрос с собеседований
Для чего нужен метод join() в потоках?🤓
Ответ:
join() заставляет текущий поток ждать завершения другого потока.
Это полезно для синхронизации выполнения, когда результат параллельной работы нужен дальше.
Правильное использование предотвращает гонки данных и обеспечивает согласованность программы.
#собеседование
Для чего нужен метод join() в потоках?
Ответ:
Это полезно для синхронизации выполнения, когда результат параллельной работы нужен дальше.
Правильное использование предотвращает гонки данных и обеспечивает согласованность программы.
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1