Java Разработка | Spring Boot Backend & Architecture. Программирование на Джава для Developer. IT Собеседования, Алгоритмы и Coding задачи. Уроки и курсы для роста в Tech.
@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 👉 @BookJava
Перейти к посту Открыть в браузере
Если у вас установлено приложение,
вы можете сразу перейти в канал