От REST к gRPC и GraphQL: современный подход к API

[@cmyser]

У графа куча проблем

Есть решение поинтереснее

https://habr.com/ru/articles/680376/ HARP human api rest protocol

[@MaDeLa]

Спасибо за ссылку на статью, очень интересно

[@Mitai]

а как дела у gRPC с http 3?

[@MaDeLa]

Хороший вопрос, спасибо.

gRPC изначально построен на HTTP/2, который обеспечивает мультиплексирование, бинарную передачу и эффективное использование соединения.
gRPC официально НЕ поддерживает HTTP/3 в стабильных продакшн-версиях на большинстве платформ (по крайней мере по состоянию на 2025 год)
Есть экспериментальная поддержка (в некоторых клиентах на C++, Go, Java), но она ограничена и пока не готова к продакшн-нагрузке.
Основная причина: HTTP/3 построен на QUIC, а это непростой стек (включает UDP, TLS 1.3 и т.д.), требующий существенной переработки как клиентов, так и серверов. gRPC использует фичи HTTP/2, которые не напрямую совместимы с HTTP/3.
Как только появятся стабильные библиотеки, обратная совместимость и поддержка в инфраструктуре, вероятно, увидим переход.

[@TeaDove]

Гибкость graphql это сразу и плюс и минус

Плюс в том, что беку не нужно думать о конкретных эндпоинтах, просто выдать доступ ко всему

Но есть минус - фронтендер может не предупредить о том, что меняет какой-то запрос. И может получится, что он поменяет запрос на что-то, что будет тригеррит Н+1 проблему

По мне graphql слишком специфичная штука, чаще рест удобнее

[@MaDeLa]

Бесспорно. Фронт может случайно нагрузить бэк: спровоцировать тяжёлый запрос или N+1.
GraphQL требует дисциплины.
На практике также встречается гибридный подход: REST - для типовых операций (создание, получение, обновление, удаление), где состав данных стабилен, GraphQL - для гибкой агрегации из микросервисов.

[@ptr128]

Когда REST лучше?

• Публичные API (легче документировать через OpenAPI).

Не меньшие возможности предоставляет рефлексия gRPC на стороне сервера.

[@MaDeLa]

Да, согласны - gRPC с рефлексией и grpcurl - мощная штука. Тут речь больше о том, что REST с OpenAPI проще для публичных API: документация сразу видна в браузере и не требует каких-то спец-инструментов.

[@ptr128]

Тут все та же проблема. Рефлексия в gRPC реализована через двунаправленный потоковый протокол, который сейчас в браузерах не поддерживается.

[@YourPapa]

А есть адекватные реализации gRPC для запросов Фронт-Бэк? Или это чисто серверная история? Типа бэк-бэк

[@ptr128]

На данный момент поддержки HTTP/2 server push нет в API браузеров. Причем тянется это уже десять лет

[@MaDeLa]

Во фронт-бэк можно использовать gRPC-Web - это адаптация gRPC под браузеры.
Он поддерживает унарные запросы и частично серверный стриминг, но С СЕРЬЁЗНЫМИ ОГРАНИЧЕНИЯМИ.

gRPC-Web требует прокси (к примеру, Envoy), не даёт привычной отладки через DevTools или Postman, не работает с JSON (только protobuf - если хочется послать json, нужно ставить gRPC-gateway или городить прослойки) и в целом требует более сложной инфраструктуры.

Вывод: фронт-бэк технически возможен, но на практике REST или GraphQL для фронта проще, лучше и надёжней.
gRPC лучше оставить для связи между микросервисами, бэк-бэк.

[@Shvedov]

А где оверфетчинг в REST? То, что ленивые люди не дали в запросе выбор полей сделать? Это не ограничение протокола, сделайте параметр с полями и возвращайте. OData вам в помощь.