Напоминание о необходимости переключить стартовую зависимость DGS на интеграцию DGS/Spring GraphQL.
Скоро это будет сделано по умолчанию, поэтому, пожалуйста, протестируйте свои приложения. Мы не заметили никаких проблем с переключением в Netflix 🙌.

https://netflix.github.io/dgs/spring-graphql-integration/

#Java #GraphQL #springboot

👉@BookJava

🔌 Проектирование API: REST, GraphQL или gRPC?


🧱 1. REST (Классика и Стандарт)

REST (Representational State Transfer) - это де-факто стандарт интернета. Большинство публичных API (GitHub, Stripe, Telegram) построены на нем.

Суть: В центре всего находится Ресурс (Существительное). А действия над ним выполняются через стандартные HTTP-методы (Глаголы).
• GET /users/123 - Дай мне пользователя 123.
• POST /users - Создай пользователя.
• DELETE /users/123 - Удали пользователя.

✅ Плюсы:

• Простота: Понятен всем, легко тестировать через Postman или браузер.

• Кэширование: Идеально работает с CDN (о которых мы говорили раньше), так как использует стандартные механизмы HTTP.

❌ Минусы:

• Over-fetching (Избыточность): Мобильному приложению нужно только имя пользователя, но метод GET /users/1 возвращает огромный JSON на 50 полей (с адресами, датами и т.д.). Вы тратите трафик впустую.

• Under-fetching (Недостаточность) и проблема N+1: Чтобы показать профиль пользователя и его 10 последних постов, фронтенду придется сделать 1 запрос к /users/1 и еще 10 запросов к /posts?userId=1. Это медленно.


🕸️ 2. GraphQL (Мечта Фронтендера)

Разработан в Facebook для решения проблем REST при слабом мобильном интернете.

Суть: У вас есть всего один Endpoint (обычно POST /graphql). Клиент сам пишет запрос-схему, где указывает, какие конкретно поля ему нужны.

Запрос клиента:

query {
  user(id: "123") {
    name
    email
    posts(last: 10) {
      title
    }
  }
}

Ответ сервера: Вернется JSON строго с именем, email и 10 заголовками постов. Ни одним байтом больше!

✅ Плюсы:

• Решает проблемы Over-fetching и Under-fetching. Один запрос = ровно те данные, что нужны для отрисовки экрана.

• Быстрая итерация фронтенда: UI-команде больше не нужно просить бэкендеров написать новый endpoint /users-with-posts-and-comments.


❌ Минусы:

• Сложность кэширования: Так как всё идет через один URL POST /graphql, вы не можете просто закэшировать это на уровне CDN (Cloudflare).

• Угроза для Базы Данных: Если клиент напишет слишком глубокий вложенный запрос (Пользователь -> Посты -> Комментарии -> Авторы комментариев -> Их посты), ваша БД просто "ляжет".


🚀 3. gRPC (Спидраннер для Микросервисов)

Разработан в Google. Если REST и GraphQL общаются с помощью удобочитаемого текста (JSON) поверх старого HTTP/1.1, то gRPC ломает эти правила.

Суть: Вы вызываете функцию на другом сервере так, будто она лежит в вашем собственном коде.
Он использует HTTP/2 (поддерживает стриминг) и Protobuf (Protocol Buffers).
Protobuf - это бинарный формат. Вместо того чтобы передавать ключи "name": "Alex", он передает просто байты по заранее оговоренной жесткой схеме (.proto файл).



✅ Плюсы:

• Невероятная скорость: Бинарный формат весит в разы меньше JSON и парсится процессором мгновенно. gRPC работает до 10 раз быстрее REST.

• Строгая типизация: Вы описываете контракты в .proto файле, и из него автоматически генерируется код и для Java-бэкенда, и для Python-клиента. Никаких ошибок "ожидал строку, пришло число".

• Стриминг: Можно открыть соединение и непрерывно лить данные в обе стороны.


❌ Минусы:

• Не читается человеком: Вы не можете просто открыть консоль браузера и посмотреть payload, там будут непонятные бинарные символы.

• Плохая поддержка браузерами: Напрямую из JavaScript в браузере gRPC вызвать сложно (нужен прокси grpc-web), поэтому для публичного фронтенда его почти не используют.


В идеальной современной архитектуре:
Мобилка общается с API Gateway по GraphQL —> Gateway общается с внутренними микросервисами по gRPC.

#SystemDesign #API #REST #GraphQL #gRPC #Java

📲 Мы в MAX

👉@BookJava